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PROTOCOLE'DE GESTION, PROCEDE DE VERIFICATION ET DE 
TRANSFORMATION D'UN FRAGMENT DE PROGRAMME TELECHARGE ET 

SYSTEMES CORRESPONDANTS 

5 L' invention concerne un protocole de gestion, un 

precede de verification, un precede de transformation d'un 
fragment de programme telecharge et les syst^mes 
correspondants, plus particulierement destines aux 
systemes informatiques embarques disposant de faibles 
10 ressources en memoire et en puissance de calcul. 

D'une maniere generale, en reference a la figure 
la, on rappelle que les systemes informatiques embarques 
10 comportent un microprocesseur 11, une memoire 
permanente, telle qu'une memoire non inscriptible 12 
15 contenant le code du programme executable, une memoire 
permanente, non volatile, reinscriptible 13 de type EEPROM 
contenant les donnees stockees dans le systeme, une 
memoire vive, volatile, 14 dans laquelle le programme 
stocke ses resultats intermediaires pendant son execution, 
20 et des dispositifs d ' entree/sortie 15 permettant au 
systeme d'interagir avec son environnement . Dans le cas ou 
le systeme informatique embarque est constitue par une 
carte a microprocesseur, du type carte bancaire, le 
dispositif d' entree/sortie 15 consiste en une liaison 
25 s6rie permettant k la carte de communiquer avec un 
terminal, tel qu'un terminal lecteur de cartes. 

Dans les systemes informatiques embarques 
cI-aj5.sXqu.e.s./: — Le_co.de_du — pxog-ramme—ex6 cute— par — te — systeme — 



est fige lors de la construction du systdme, ou, au plus 
30 tard, lors de la personnalisation de ce dernier avant 
livraison k 1 ' utilisateur final. 



) 

2 

Des systemes inf oriaatiques embarques plus evolues 
ont toutefois ete mis en oeuvre, ces systemes etant 
reprogrammables, comme par exemple les cartes a 
microprocesseur de type JavaCard. Ces systemes 
reprogrammables ajoutent, vis-a-vis des precedents, la 
possibilite d'enrichir le programme apr^s la mise en 
service du systeme, par une operation de telechargement de 
fragments de programmes. Ces fragments de programmes, 
communement d§signes par "applets" en langage anglo-saxon, 
seront indif f eremment designes par appliquettes ou 
fragments de programmes dans la presente description. Pour 
une description plus detaillee des systSmes JavaCard, on 
pourra utilement se reporter a la documentation editee par 
la societe SUN MICROSYSTEMS INC. Et en particulier a la 
documentation disponible electroniquement , chapitre 
JavaCard technology sur le site W,W.W, {World Wide Weh) 
http : // j ava . sun . com/products/ j avacard/ index . html , j uin 

1999. 

La figure lb ilustre 1 ' architecture d^un tel 

systeme informatique embarque reprogrammable. Cette 
architecture est semblable a celle d'un systeme embarque 
classique, a la difference que le systeme embarque 
reprogrammable peut en outre recevoir des appliquettes par 
1 ' intermediaire d'un de ses dispositifs d' entree/sortie, 
puis stocker ces dernieres dans sa memoire permanente 13 a 
partir de laquelle elles peuvent ensuite etre executees en 
complement du programme principal . 

^Pou-r — des — ^r ad-sons — de—port-abi-i-rte — entxe — ^drfferents— 

systemes informatiques embarques, les appliquettes se 
presentent sous forme de code pour une machine virtuelle 
standard. Ce code n'est pas directement executable par le 
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microprocesseur 11 mais doit etre interpr6te de mani^re 
logicielle par une machine virtuelle 16, laquelle est 
constituee par un programme residant en memoire permanente 
non inscriptible 12. Dans I'exemple precite des cartes 
5 JavaCard, la machine virtuelle utilisee est un sous- 
ensemble de la machine- virtuelle Java. Pour une 
description des specifications relatives a la machine 
virtuelle Java et de la machine virtuelle utilisee, on 
pourra atilement se reporter a I'ouvrage publie par Tim 
10 LINDHOLM et Frank YELLIN, intitule "The Java Virtual 
Machine Specification", Addison-Wesley 1996, et a la 
documentation edit6e par la societe SUN MICROSYSTEMS INC. 
"JavaCard 2.1 Virtual Machine Specification", 
documentation disponible electroniquement sur le site 
15 W . W . W . http : // j ava . sun . com/products/ j avacard/JCVMSpec . pdf , 
mars 1999. 

L' operation de telechargement d' appliquettes sur 
un systeme informatique embarque en service pose 
d'importants problemes de securite. Une appliquette 

20 involontairement , voire volontairement , mal ecrite peut 
modifier de maniere incorrecte des donnees presentes sur 
le systeme, empecher le programme principal de s'executer 
correctement ou en temps voulu, ou encore modifier 
d'autres appliquettes telechargees anterieurement, en 

25 rendant celles-ci inutilisables ou nuisibles. 

Une appliquette ecrite par un pirate informatique 
peut egalement divulguer des informations conf identielles 

s-t-Qckaes—dans—le— s-ys-t-eme-, — i-n-fo^ma>t4^ns— feeil-es— qure — le c ede — 

d'acces dans le cas d'une carte bancaire par exemple. 
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A I'heure actuelle, trois solutions ont ete 
proposees en vue de remedier au probleme de securite des 
appliquettes . 

Une premiere solution consiste a utiliser des 
signatures cryptographiques afin de n' accepter que des 
appliquettes provenant de personnes ou d'organismes de 
confiance. 

Dans I'exemple d'une carte bancaire precite, seules les 
appliquettes portant la signature cryptographique de la 
banque ayant 6mis la carte sont acceptees et executees par 
la carte, toute autre appliquette non signee etant rejetee 
au cours de 1' operation de telechargement . Un utilisateur 
mal intentionne de la carte, ne disposant pas de cles de 
chiffrement de la banque, sera done dans 1 ' incapacite de 
faire executer une appliquette non signee et dangereuse 
sur la carte. 

Cette premiere solution est bien adaptee au cas ou toutes 
les appliquettes proviennent d^une meme source unique, la 

banque dans I'pxpmplp precite. Cette solution est 

20 dif f icilement applicable au cas ou les appliquettes 
proviennent de plusieurs sources, comme, dans I'exemple 
d'une carte bancaire, le fabricant de la carte, la banque, 
les organismes gestionnaires des services par carte 
bancaire, les grands organismes de distribution 
25 commerciale of f rant a la clientele des programmes de 
fid61isation et proposant, legitimement , de telecharger 
des appliquettes specif iques sur la carte, Le partage et 
la d"§~tenirion entre ces divers acteurs economiques des cles 
de chiffrement necessaires a la signature electronique des 

30 appliquettes posent des problemes techniques, economiques 
et juridiques majeurs. 
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Une deuxieme solution consiste ^ effectuer des 
controles dynamiques d'acces et de typage pendant 
1' execution des appliquettes . 

Dans cette solution, la machine virtuelle lors de 
1' execution des appliquettes, effectue un certain nombre 
de controles, tels que : 

- controle d'acces a la memoire : a chaque lecture ou 
ecriture d'une zone memoire, la machine virtuelle 
verifie le droit d'acces de 1 ' appliquette aux donnees 
correspondantes ; 

- verification dynamique des types de donnees : a chaque 
instruction de 1 ' appliquette, la machine virtuelle 
verifie que les contraintes sur les types de donnees 
sont satisfaites. A titre d'exemple, la machine 
virtuelle peut traiter specialement les donnSes telles 
que des adresses memoire valides et empecher que 
1 ' appliquette n'engendre des adresses memoire invalides 
par 1 ' intermediaire de conversions entier/adresse ou 
d' operations arithmetiques sur les adresses ; 

20 - detection des debordements de pile et des acces 
illegaux dans la pile d' execution de la machine 
virtuelle, lesquels, dans certaines conditions, sont 
susceptibles de perturber le fonctionnement de cette 
derniere, au point de contourner les m6canismes de 
25 controle precedents. 

Cette deuxieme solution permet 1' execution d'une large 
gamme d' appliquettes dans des conditions de securite 

saiis-falsantes ^El-le — ^presen-fee — ^feeu^e-fo-i-s — l-m-neonventent — 

d'un ralentissement considerable de 1' execution, provoque 
30 par 1' ensemble des verifications dynamiques. Pour obtenir 
une reduction de ce ralentissement, une partie de ces 
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verifications peut etre prise en charge par le 
microprocesseur lui-meme, au prix toutefois d'une 
augmentation de la complexite de ce dernier et done du 
prix de revient du systeme embarque. De telles 
5 verifications augmentent en outre les besoins en memoire 
vive et permanente du systeme, en raison des informations 
supplementaires de type qu'il est necessaire d'associer 
aux donn6es manipulees. 

Une troisieme solution consiste gl effectuer une 
10 verification statique du code de 1 ' appliquette lors du 
telechargement • 

Dans cette solution, cette verification statique simule 
1' execution de 1 ' appliquette au niveau des types de 
donnees et etablit, une fois pour toutes, que le code de 

15 1 ' appliquette respecte la rSgle des types de donnees et de 
contrdle d'acces imposee par la machine virtuelle et ne 
provoque pas de debordement de pile. Si cette verification 
statique reussit, 1 ' appliquette peut alors etre execute 

aans qi] ' 1 1 — so1 1 — necessa ire — — verifier — dynamiqu e m e nt — quo 

20 cette regie est respectee. Dans le cas ou le processus de 
verification statique echoue, le systeme embarque re jette 
1^ "appliquette" et ne permet pas son execution ulterieure. 
Pour une description plus detaillee de la troisieme 
solution precitee, on pourra utilement se reporter a 

25 I'ouvrage edit§ par Tim LINDHOLM et Frank YELLIN 
prec6demment cite, a l*article publi6 par James A. GOSLING 
intitule "Java Intermediate Byte Codes", Actes du ACM 
STlSPiair; Worlcshop on Intermediate Representations (IR' 95) , 
pages 111-118, janvier 1995,. et au brevet US 5,748,964 

30 delivre le 05/05/1998 • 
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Vis-a-vis de la deuxieme solution, la troisieiae 
solution presents I'avantage d'une execution des 
appliquettes beaucoup plus rapide, puisque la machine 
virtuelle n'effectue aucune verification pendant 
1' execution. 

La troisieme solution presente toutefois 1 ' inconvenient 
d'un processus de verification statique du code complexe 
et coQteux, tant en taille de code necessaire pour 
conduire ce processus, qu'en taille de memoire vive 
necessaire pour contenir les resultats intermediaires de 
la verification, et qu'en temps de calcul. A titre 
d'exemple illustratif, la verification de code integre 
dans le systeme Java JDK commercialise par SUN 
MICROSYSTEMS represente de I'ordre de 50 k-octets de code 
15 machine, et sa consommation en memoire vive est 
proportionnelle a (Tp + Tr) xbTb ou Tp designe 1 ' espace 
maximum de pile, Tr designe le nombre maximum de registres 
et Nb designe le nombre maximum de cibles de branchements 

utilisees par un sous-programme, encore commun^ment 

20 designe par methode, de 1 'appliquette Ces besoins en 
memoire depassent largement les capacites des ressources 
de la majorite des syst^mes informatiques embarques 
actuels, notamment des cartes a microprocesseur 
commercialement disponibles. 
25 Plusieurs variantes de la troisiSme solution ont ete 
proposees, dans lesquelles l'6diteur de 1 ' appliquette 
transmet au v6rif icateur, outre le code de 1 'appliquette, 

^ eer-t-ai-n nombre ^d-'-informatrron-s s upp"lremen:t aires — 

specifiques telles que types de donnees precalcules ou 
30 preuve preetablie de typage de donnees correct. Pour une 
description plus detaillee des modes operatoires 



correspondants, on pourra utilement se reporter aux 
articles publies par Eva ROSE et Kristoffer H0GSBRO ROSE, 
"Lightweight Bytecode Verification", Actes du Workshop 
Foriaal Underspinning of Java, Octobre 1998, et par George 
5 C. NECULA, "Proof "Carrying Code'\ Actes du 24^ ACM 
Symposium Principles of Programming Languages, pages 
106-119 respectivement . 

Ces informations supplementaires permettent de verifier le 
code plus rapideiaent et de reduire legerement la taille du 
10 code du programme de verification mais ne permettent 
toutefois pas de reduire les besoins en memoire vive, 
voire les augmentent, de maniere trSs importante, dans le 
cas des informations de preuve preetablie de typage de 
donnees correct . 

15 La presente invention a pour objet de remedier aux 

inconvenients precites de 1 ' art anterieur. 

En particulier, un objet de la presente invention 
est la mise en oeuvre d'un protocole de gestion d'un 

fragment de programme, ou appliguette. telecharge 

20 permettant une execution sur de ce dernier par un systeme 
informatique embarque disposant de faibles ressources, tel 
qu'une carte a microprocesseur . 

Un autre objet de la presente invention est 
egalement la. mis oeuvre d'un proced§ de verification 

25 d'un fragment de. programme, ou applique tte, telecharge 
dans lequel un processus de verification statique du code 
de 1' appliquette est conduit lors de son telechargement , 
^ce pro-ce-s-sus p'ouvant §"t"re rapprocfire; au — m^i"ns — dans — son — 
principe, de la troisieme solution precedemment decrite, 
30 mais dans lequel des techniques nouvelles de verification 
sont introduites, afin de permettre 1' execution de cette 



verification dans les limites de valeurs de taille memoire 
et de Vitesse de calcul iiaposees par les cartes a 
microprocesseur et autres systemes inf ormatiques embarques 
peu puissants, 

Un autre objet de la presente invention est 
egalement la mise en oeuvre de precedes de transformation 
de fragments de programmes de type classique obtenus par 
exemple par la mise en oeuvre d'un compilateur Java en 
fragments de programmes, ou appliquettes, normalises, 
satisfaisant a priori aux criteres de verification du 
proced§ de verification objet de 1' invention, en vue 
d^accelerer le processus de verification et d' execution de 
ces derniers au niveau des systSmes informatiques 
embarques ou cartes a microprocesseur actuels. 

Un autre objet de la presente invention est, 
enfin, la realisation de systemes informatiques embarques 
permettant la mise en oeuvre du protocole de gestion et du 
procede de verification d'un fragment de programme 
telecharge precites ainsi que de systemes informatiques 
20 permettant la mise en oeuvre des precedes de transformation 
de fragments de programmes, ou appliquettes, classiques en 
fragments de programmes, ou appliquettes, normalises 
precites. 

Le protocole.de gestion d'un fragment de programme 
25 telecharge sur un systeme embarcjue reprogrammable, objet 

de la presente invention, s' applique notamment k une carte 

k microprocesseur munie d'une memoire r6inscriptible . Le 
feagmen-fe — de — ^p-reg-rarame — es-t — eons-fe-i-bue — ^pa-r — ^un — code — obj-et"7 — 

suite d' instructions, executable par le microprocesseur du 
30 systeme embarque par 1 ' intermediaire d'une machine 

virtuelle munie d'une pile d' execution et de registres ou 
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variables locales luanipulees par ces instructions et 
peritiettant d' interpreter ce code objet. Le systeme 
eitibarque est interconnecte a un terminal. 

II est remarquable en ce qu'il consiste au moins, au 
5 niveau du systeme embarque, a detecter une commande de 
telechargement du fragment de programme • Sur reponse 
positive a I'etape consistant ^ detecter une commande de 
telechargement, il consiste en outre a lire le code objet 
const itutif du fragment de programme et ^ memoriser 

10 temporairement ce code objet dans la memoire 
r^inscriptible . L' ensemble du code objet memorise est 
soumis a un processus de verification instruction par 
instruction. Le processus de verification consiste au 
moins en une etape d' initialisation de la pile des types 

15 et du tableau des types de registres representant I'etat 
de la machine virtuelle au d§but de 1' execution du code 
objet memorise temporairement et en une succession 
d'etapes de verification instruction par instruction de 

1 ' Rxi .sf pncp^ ponr chaqug instruction courante, d'un e 

20 cible, cible d' instruction de branchement, cible d*un 
gestionnaire d' exceptions, et en une verification et une 
actualisation de I'effet de 1 ' instruction courante sur la 
pile des types et sur le tableau des types de registres. 
Dans le cas d'une verification non reussie du code objet, 
25 le protocole objet de 1' invention consiste cl ef facer le 
fragment de programme enregistre moment anement, en 
1' absence d ' enregistrement de ce dernier dans le 



reperfol^re de fragments de programmes disponibles, et a 
adresser au lecteur un code d'erreur. 
30 Le precede de verification d'un fragment de 

programme telecharge sur un systeme embarque, objet de 



11 



1' invention, s" applique notamment a une carte a 
microprocesseur munie d'une memoire reinscriptible . Le 
fragment de programme est constitue par un code objet et 
comporte au moins un sous-programme, suite d * instructions, 
5 executable par le microprocesseur du systeme embarque par 
1 ' intermediaire d'une machine virtuelle munie d ' une pile 
d' execution et de registres d'operandes manipules par ces 
instructions et permettant d' interpreter ce code objet. Le 
systeme embarque est interconnects a un lecteur. 
10 II est remarquable en ce que, suite A la detection d'une 
coramande de telechargement et a la memorisation du code 
objet constitutif du fragment de programme dans la memoire 
reinscriptible, il consiste, pour chaque sous-programme, a 
effectuer une etape d ' initialisation de la pile des types 
15 et du tableau des types de registres par des donnees 
representant I'etat de la machine virtuelle au debut de 
1' execution du code objet memorise temporairement , a 
effectuer une verification du code objet memorise 
temporairement instruction par instruction, par 
20 discrimination de 1' existence, pour chaque instruction 
courante, d'une cible d * instruction de branchement, d'une 
cible d'un appel d'un gestionnaire d' exceptions ou d'une 
cible d'un appel de sous-routine et a effectuer une 
verification et une actualisation de I'effet de 
25 1 • instruction courante sur les types de donnees de la pile 
des types et du tableau des types de registres, en 
fonction de 1' existence d'une cible d' instruction de 

bxanch.emen-t., — d— une — ci-b-le — d— un — appe-1 — de — sou-s--^eu^ti-ne — ou— 

d'une .cible d'un appel de gestionnaire d ' exceptions . La 
30 verification est reussie lorsque le tableau des types de 
registres n'est pas modifie au cours d'une verification de 
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toutes les instructions, le processus de verification 
etant poursuivi instruction par instruction jusqu'a ce que 
le tableau des types de registres soit stable, en 
1' absence de modification. Le processus de verification 
est interrompu sinon. 

Le precede de transformation d'un code objet d'un 
fragment de programme en un code objet normalise pour ce 
meme fragment de programme, objet de la presente 
invention, s' applique a un code objet d'un fragment de 
programme dans lequel les operandes de chaque instruction 
appartiennent aux types de donn^es manipulees par cette 
instruction, la pile d' execution ne pr6sente pas de 
phenomdne de debordement et pour chaque instruction de 
branchement le type des variables de la pile au niveau de 
ce branchement est le meme qu'au niveau des cibles de ce 
branchement. Le code objet normalise obtenu est tel que 
les operandes de chaque instruction appartiennent aux 
types de donnees manipulees par cette instruction, la pile 
d' execution ne presente pas de phenomene de debordement et 
la pile d' execution est vide a chaque instruction de cible 
de branchement. 

II est remarquable en ce qu'il consiste, pour 1' ensemble 
des instructions du code objet, a annoter chaque 
instruction courante par le type de donnees de la pile 
d' execution avant et apres 1' execution de cette 
instruction, les donnees d' annotation etant calculees au 
moyen d'une analyse du flot des donnees relatif ^ cette 
-iTTstructi-on-T a— deiie-ct-er— aa~s-e-i:n— d'e's — xn-stru-cti-p-n-s; — et~ae~~ 
•chaque instruction courante, 1' existence de branchements 
pour lesquels la pile d'execution n'est pas vide, 
1* operation de detection etant conduite a partir des 
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donnees annotation du type de variables de pile allouees 
a chaque instruction courante. En presence d'une detection 
d'une pile d' execution non vide, il consiste en outre a 
insurer des instructions de transfert des variables de 
5 pile de part et d' autre de ces branchements ou de ces 
cibles de branchement afin de vider. le contenu de la pile 
d* execution dans des registres temporaires avant ce 
branchement et de retablir la pile d' execution a partir 
des registres temporaires apres ce branchement et a 

10 n'inserer aucune instruction de transfert sinon, 

Ce precede permet ainsi d'obtenir un code objet normalise 
pour ce m§me fragment de programme, dans lequel la pile 
d' execution est vide i chaque instruction de branchement 
et de cible de branchement, en 1' absence de toute 

15 modification de 1' execution du fragment de programme. 

Le procede de transformation d'un code objet d'un 
fragment de programme en un code objet normalise pour ce 
meme fragment de programme, objet de la presente 
invention, s' applique, en outre, a un code objet d'un 

20 fragment de programme dans lequel les operandes de chaque 
instruction appartiennent aux types de donnees manipulees 
par cette instruction, et un operande de type determine 
ecrit dans un registre par une instruction de ce code 
objet est relu depuis ce meme registre par une autre 
25 instruction de ce code objet avec le meme type de donnee 
determine. Le code objet normalise obtenu est tel que les 
op6randes appartiennent aux types de donnees manipulees 
^par — cett-e — ins-truction., — ^un — s-eul — et — meme — ^t-ype — de — donnee — 



etant alloue k un meme registre dans tout le code objet 
30 normalise. 
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II est remarquable en ce qu'il consiste, pour 1' ensemble 
des instructions du code objet, a annoter chaque 
instruction courante par le type de donnee des registres 
avant et apres 1 ' execution de cette instruction, les 
5 donnees d' annotation etant calculees au moyen d'une 
analyse du flot des donnees relatif a cette instruction, 
et a effectuer une reallocation des registres d'origine 
employes avec des types differents, par division de ces 
registres d'origine en registres normalises distincts. Un 
10 registre normalise est alloue a chaque type de donnee 
utilise. Une reactualisation des instructions qui 
manipulent les operandes qui font appel aux registres 
normalises est effectuee, 

Le protocole de gestion d'un fragment de 
15 programme, le procede de verification d'un fragment de 
programme, les precedes de transformation de code objet de 
fragments de programmes en code objet normalise et les 
systemes correspondants, objet s de la presente invention, 

: trpuvent ^ppjication au d^v^lnpp^m Qnt dg><s .gygt-giTn^Q 

20 embarques reprogrammables, tels que. les cartes a 
microprocesseur, notamment dans 1 ' environnement Java. 

II seront mieux compris a la lecture de la 
description et a 1 ' observation des dessins ci-apr§s, dans 
lesquels, outre les figures la et lb relatives k I'art 
25 anterieur : 

- la figure 2 repr6sente un organigramme illustratif du 
protocole de gestion d'un fragment de programme 
teFecharge sur un systeme embarque reprogrammable, 

- la figure 3a represente, a titre illustratif, un 
30 organigramme d'un procede de verification d'un fragment 
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de programme telecharge conformement a I'objet de la 
presente invention, 

la figure 3b represente un diagramiue illustratif des 
types de donnees et des relations de sous-typage mis en 
5 oeuvre par le procede de gestion et le procede de 

verification d'un fragment de programme telecharge, 
objet de la presente invention, 

- la figure 3c represente un detail du procede de 
verification selon la figure 3a, relatif a la gestion 

10 d'une instruction de branchement, 

la figure 3d represente un detail du procede de 
verification selon la figure 3a, relatif a la gestion 
d'une instruction d'appel de sous-routine, 
la figure 3e represente un detail du procede de 
15 verification selon la figure 3a, relatif a la gestion 

d'une cible d'un gestionnaire d' exceptions, 
la figure 3f represente un detail du procede de 
verification selon la figure 3a, relatif a la gestion 

d'line rihip dp hranrhempnts i ncompat i b1 es, 

20 - la figure 3g represente un detail du procede de 
verification selon la figure 3a, relatif a la gestion 
d'une absence de cible de branchement, 

- la figure 3h represente un detail du precede de 
verification selon la figure 3a, relatif k la gestion 

25 de I'effet de 1 ' instruction courante sur la pile des 

types, 

- la figure 3i represente un detail du procede de 
verification selon la figure 3a, relatif a la gestion 
d'une instruction de lecture d'un registre. 
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- la figure 3j represente un detail du precede de 
verification selon la figure 3a, relatif a la gestion 
d'une instruction d'ecriture d'un registre, 

- la figure 4a represente un organigramme illustratif 
d'un procede de transformation d'un code objet d'un 
fragment de programme en un code objet normalise pour 
ce meme fragment de programme a instruction de 
branchement respectivement de cible de branchement a 
pile vide, 

- la figure 4b represente un organigramme illustratif 
d'un procede de transformation d'un code objet d'un 
fragment de programme en un code objet normalise pour 
ce meme fragment de programme faisant appel a des 
registres types, a chaque registre etant attribue un 
seul type de donnee specifique, 

- la figure 5a represente un detail de mise en oeuvre du 
procede de transformation illustre en figure 4a, 

- la figure 5b represente un detail de mise en oeuvre du 
prorpde rip transfnrTnat i on illustri? gn f i gure 4b, 

2^ " 1^ figure 6 represente un schema fonctionnel de 
1' architecture complete d'un systeme de developpement 
d'un fragment de programme normalise, et d'une carte ^ 
microprocesseur reprogrammable permettant la mise en 
oeuvre du protocole de gestion et du procede de 
25 verification d'un fragment de programme conformement a 

1' objet de la presente invention. 

D'une maniere generale, on indique que le 
protocole de gestion, le procede de verification et de 
transformation d'un fragment de programme telecharge, 
30 objet de la presente invention, ainsi que les systemes 
correspondants, sont mis en oeuvre grace a une architecture 
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logicielle pour le telechargeiaent et 1' execution surs 
d' appliquettes sur un systeme inf ormatique embarque 
disposant de faibles ressources, tel que notamment les 
cartes a rnicroprocesseur • 
5 D'une maniere generals, on indique que la 

description ci-apres concerne 1 ' application de 1' invention 
dans le contexte des cartes d rnicroprocesseur 
reprogramitiables de type JavaCard, confer documentation 
disponible electroniquement aupres de la societe SUN 
10 MICROSYSTEMS INC. rubrique JavaCard Technology 
precedemment mentionnee dans la description, 

Toutefois, la presente invention est applicable a 
tout systeme embarque reprogrammable par 1 ' intermediaire 
d'un tel§chargement d'appliquette ecrite dans le code 
15 d'une machine virtuelle comprenarit une pile d' execution, 
des registres ou variables locales et dont le modele 
d' execution est fortement type, chaque instruction du code 
de 1 ' appliquette ne s'appliquant qu'a des types de donnees 
specifiques. Le protocole de gestion d'un fragment de 
20 programme telecharge sur un systeme embarque 
reprogrammable, objet de la presente invention, sera 
maintenant decrit de maniere plus detaillee en liaison 
avec la figure 2* 

En liaison avec la figure precitee, on indique que 
25 le code objet constitutif du fragment de programme ou 
appliquette est constitue par une suite d' instructions 
executables par le microprocesseur du systeme embarque par 

1 ' intermediaire de la mac hine 5clr.tue.ll.e ^pracedemment 

mentionnee. La machine virtuelle permet d^ interpreter le 
30 code objet precite, Le systeme embarque est interconnecte 
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a un terminal par 1 ' interiaediaire d'une liaison serie par 
exemple . 

En reference a la figure 2 precedemment 
mentionnee, le protocole de gestion objet de la presente 
invention consiste au laoins, au niveau du systeme 
embarque, k detecter en une etape 100a, 100b, une coinmande 
de telechargement de ce fragment de programme. Ainsi, 
l'6tape 100a peut consister en une etape de lecture de la 
commande pr§citee et 1' etape 100b en une etape de test de 
la commande lue et de verification de 1' existence d'une 
commande de telechargement. 

Sur reponse positive ^ 1' etape de detection lOOa, 
100b precitee d'une commande de telechargement, le 
protocole objet de la presente invention consiste ensuite 
a lire a 1' etape 101 le code objet constitutif du fragment 
de programme considere et a memoriser temporairement le 
code objet precite dans la memoire reinscriptible du 
systeme informatique embarque. L' etape de lecture du code 
objet et de memorisation temporaire de ce dernier dans la 
memoire reinscriptible est designee par chargement du code 
de 1 ' appliquette sur la figure 2. 

L' etape precitee est alors suivie d'une etape 102 
consistant a soumettre 1 'ensemble du code objet memorise 
temporairement a un processus de verification, instruction 
par instruction, du code objet precit6. 

Le processus de verification consiste au moins en 
une etape d' initialisation de la pile des types et du 
tabieau— des — types— de—donn-e-e-s—rep-resentant — l-'-erat~^e — la — 
machine virtuelle au debut de 1' execution du code objet 
memorise temporairement, ainsi qu'en une succession 
d'etapes de verification instruction par instruction par 
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discrimination de 1' existence, pour chaque instruction 
courante, notee Ii, d'une cible telle qu'une cible 
d' instruction de branchement notee CIB, une cible d'appel 
d'un gestionnaire d' exceptions ou une cible d'un appel de 
5 sous-routine. Une verification et une actualisation de 
I'effet de 1 ' instruction courante Ii sur la pile des types 
et sur le tableau des types de registres est effectuee. 

Lorsque la verification est reussie a I'etape 
103a/ le protocole objet de la presente invention consiste 
10 a enregistrer ^ I'etape 104 le fragment de programme 
telecharge dans un repertoire de fragments de programmes 
disponibles et a envoyer a I'etape 105 au lecteur un 
accuse de reception positif . 

Au contraire, dans le cas d'une verification non 
15 reussie du code objet ^ l'6tape 103b/ le protocole objet 
de 1' invention consiste ^ ef facer a I'etape 106 le 
fragment de programme enregistre momentanement en 
1' absence d' enregistrement de ce fragment de programme 
dans le repertoire de fragments de programmes disponibles 
20 et, a une etape 107, a adresser au lecteur un code 
d'erreur. Les etapes 107 et 105 peuvent etre realisees 
soit sequentiellement apres les etapes 106 respectivement 
104/ soit en operation multitache avec celles-ci. 

En reference a la meme figure 2, sur reponse 
25 negative a I'etape consistant k d6tecter une commande de 
tel^chargement a I'etape 100b/ le protocole objet de la 
presente invention consiste a detecter/ en une §tape 108/ 
^une — commande — de — S-aLection — d— un — fragment — de ^p-rog-ramme 



disponible dans un repertoire de fragments de programmes 
30 et/ sur reponse positive a I'etape 108, la selection d'un 
fragment de programme disponible etant detectee, a appeler 
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a l'6tape 109 ce fragment de programme disponible 
sfelectionne en vue de son execution. L'etape 109 est alors 
suivie d'une 6 tape d' execution 110 du fragment de 
programme disponible appele par 1 • intermediaire de la 
machine virtuelle en 1' absence de toute verification 
dynamique de types de variables, des droits d'acces aux 
Ob jets manipules par le fragment de programme disponible 
appele ou du debordement de la pile d' execution lors de 
1' execution de chaque instruction. 

Dans le cas ou une reponse negative est obtenue ^ 
l'etape 108, cette etape consistant a d^tecter une 
commande de selection d'un fragment de programme 
disponible appele, le protocole objet de la presente 
invention consiste A proc6der, ^ une etape 111, au 
15 traitement des commandes standard du systSme embarqu6. 

En ce qui concerne 1' absence de verification 
dynamique de type ou de droit d'acces aux objets de type 
JavaCard par exemple, on indique que cette absence de 
verification ne compromet pas la .':;^'^r^^4. Hg. ia o..r^^a ^^j - 

code de 1 ' appliquette a necessairement passe avec succ^s 
la verification. 

D'une maniere plus specif ique, on indique que la 
verification de code effectuee, conform^ment au precede 
objet de 1' invention, sur la carte ^ microprocesseur ou 
sur le systeme informatique embarque est plus selective 
que la verification habituelle de codes pour la machine 
virtuelle Java telle que d§crite dans I'ouvrage intitul§ 
-"The ztava Vtrtira-1 MscTlrtns — Specrflcatl-on" — pr-gce demment — 
mentionne dans la description. 

Toutefois, tout code de la machine virtuelle Java 
correct au sens du verificateur Java traditionnel peut 
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etre transforme en un code equivalent susceptible de 
passer avec succ^s la verification de code effectuee sur 
la carte a microprocesseur . 

Alors qu'il est possible d'envisager I'ecriture 
5 directe de codes Java satisfaisant aux criteres de 
verification precedemment mentionnes dans le cadre de la 
mise en oeuvre du protocole objet de la presente invention, 
un objet reiaarquable de celle-ci est egalement la mise en 
ceuvre d'un precede de transformation automatique de tout 
10 code Java standard en un code normalise pour le mSme 
fragment de programme satisfaisant necessairement aux 
critdres de verification mis en ceuvre precedemment cites. 
Le precede de transformation en code normalise et le 
systSme correspondant seront decrits ulterieurement dans 
15 la description de mani^re detaill6e, 

Une description plus detaillee du precede de 
verification d'un fragment de programme, ou appliquette, 
conforme a 1' objet de la pr§sente invention, sera 
maintenant donnee en liaison avec la figure 3a et les 
20 figures suivantes, 

D'une maniere generale, on indique que le precede 
de verification objet de la presente invention peut etre 
mis en oeuvre soit dans le cadre du protocole de gestion 
d'un fragment de programme objet de 1' invention 
25 precedemment decrit en liaison avec la figure 2, soit de 
manidre ind§pendante, afin d' assurer tout processus de 
verification juge necessaire. 
D-Lune— mani.er.e_gen.ex.ale., ^on_indi.que_qulJiri_£ragment_ 



de programme est constitue par un code objet comportant au 
30 moins un sous-programme, plus communement designe par 
methode, et constitu6 par une suite d' instructions 
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ex4cutables par le microprocesseur du syst^me embarque par 
1 • interm^diaire de la machine virtuelle. 

Ainsi que represente sur la figure 3a, le precede 
de verification consiste, pour chaque sous-programme, a 
effectuer une etape 200 d' initialisation de la pile des 
types et du tableau des types de registres de la machine 
virtuelle par des donnees representant I'etat de cette 
machine virtuelle au debut de 1' execution du code objet, 
Ob jet de la verification. Ce code objet peut §tre memorise 
temporairement ainsi que d6crit pr6c§deinment en liaison 
avec la mise en oeuvre du protocole objet de la presente 
invention . 

L' etape 200 precitee est alors suivie d'une etape 
200a consistant A positionner la lecture de 1 ' instruction 
courante li, index i, sur la premiere instruction . du code 
objet. L'6tape 200a est suivie d'une etape 201 consistant 
^ effectuer une verification du code objet precit6 
instruction par instruction, par discrimination pour 
. Chaque instruction couranfe notp^ t. Hp t f^ x T <,t^nn^ H'nr.o 
cible d' instruction de branchement CIB, d'une cible d'un 
appel de gestionnaire d' exceptions, note CEM, ou d'une 
cible d'un appel de sous-routine CSR. 

L' etape de verification 201 est suivie d'une etape 
de verification 202 et d' actualisation de I'effet de 
1' instruction courante Ii sur les types de donnees de la 
pile des types et du tableau des types de registres en 
fonction de 1' existence, pour 1 ' instruction courante visee 
p-ax— une autre in5trucri"on7 9"' une-Vi&re~^'llis"truceiW~ae~ 
branchement CIB, d'une cible d'un appel de sous-routine 
CSR ou d'une cible d'un appel de gestionnaire d' exceptions 
CEM. 
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L'etape 202 pour 1 ' instruction courante It est 
suivie d'une etape de test 203 d'atteinte de la derniere 
instruction, test note : 

li = dernidre instruction du code objet ? 
5 Sur reponse negative au test 203, le processus passe a 
1 ' instruction suivante 204, note i = i+1, et au retour a 
1' etape 201. 

On indique que la verification precitee, a 1' etape 
202, est reussie lorsque le tableau des types de registres 
10 n'est pas modifiS au cours d'une verification de toutes 
les instructions Ii constitutives du code objet. Dans ce 
but, un test 205 d' existence d'un 6tat stable du tableau 
des types de registres et pr§vu. Ce test est note : 
3? Etat stable du tableau des types de registres. 
15 Sur reponse positive au test 205, la verification a 
reussi. 

Dans le cas ou au contraire aucune absence de 
modification est constatee, le processus de verification 

est reitere et relance par retour a 1' etape 200a, On 

20 demontre que la fin du processus est garantie apres au 
plus NrxH iterations, ou Nr designe le nombre de registres 
utilises et H une constante dependant de la relation de 
sous-typage. 

Differentes indications relatives aux types de 
25 variables manipulees au cours du processus de verification 
d6crit precedemment en liaison avec la figure . 3a seront 
maintenant donnees en liaison avec la figure 3b. 

^Les — ^feypes — de — ^va-riab-tes — ^pr-eei-tes — eompo-r-tenrt — ^au— 



moins des identif icateurs de classes correspondant aux 
30 classes d'objets definis dans le fragment de programme 
soumis ^ la verification, des types de variables 
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num6riques comportant au moins un type short , entier code 
sur p bits, p pouvant prendre la valeur p = 16, et un type 
d'adresse de retour d'une instruction de saut JSR, ce type 
d'adresse etant note retaddr , un type null relatif a des 
references d'objets nuls, un type object relatif aux 
objets proprement dits, un type specif ique 1 representant 
1' intersection de tous les types et correspondant k la 
valeur z^ro nul, un autre type specifique T representant 
1' union de tous les types et correspondant a tout type de 
valeurs . 

En reference A la figure 3b, on indique que 
1 'ensemble des types de variables pr6cites verifient une 
relation de sous-typage : 
obj ect e T ; 
short, retaddr e T / 
l_e null , short , retaddr 

Un exemple plus specifique d'un processus de 
verification tel qu'illustre en figure 3a sera maintenant 
Joiwiti eii iidisbft aV6c Un premier exemple de structure.de 
donn^es illustre au tableau Tl joint en annexe. 

L' exemple pr§cite concerne une appliquette ecrite 
en code Java. 

Le processus de verification accede au code du 
sous-programme constitutif de 1 • appliquette soumis ^ 
verification par 1 ' intermediaire d'un pointeur sur 
1 ' instruction li en cours de verification. 

Le processus de verification enregistre la taille 
et le type de la pile d' execution au niveau de 
1' instruction courante Ii correspondant k saload sur 
1' exemple du tableau Tl precite. 
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Le processus de verification enregistre alors la 
taille et le type de la pile d' execution au niveau de 
1 ' instruction courante dans la pile des types par 
1 ' intermediaire de son pointeur de pile des types. 
5 Ainsi que itientionne precedemment dans la 

description, cette pile de types reflete I'etat de la pile 
d' execution de la machine virtuelle au niveau de 
1 ' instruction courante Ii. Dans 1' example represente au 
tableau Tl, lors de 1' execution future de 1 ' instruction 

10 Ii, la pile contiendra trois entrees : une reference vers 
un objet de la classe C, une reference vers un tableau 
d'entiers codes sur p = 16 bits, le type short [], et un 
entier de p = 16 bits de type short , Ceci est 6galement 
represente dans la pile des types qui contient 6galement 

15 trois entrees : C, le type des objets de la classe C, 
short [], le type des tableaux d'entiers p = 16 bits et 
short , le type des entiers p = 16 bits. 

Une autre structure de donnees remarquable est 
constitute par un tableau de types de registres, ce 

20 tableau refletant I'etat des registres, c'est-a-dire des 
registres m6morisant les variables locales, de la machine 
virtuelle . 

En continuant I'exemple indique au tableau Tl, on 
indique que 1' entree 0 du tableau de types de registres 

25 contient le type C, c'est-a-dire que lors de 1' execution 
future de 1 ' instruction courante Ii = saload, le registre 
0 est assure de contenir une reference vers un objet de la 

c±a:sse~e-:^ 



Les dif f erents types manipules au cours de la 
30 verification et stockes dans le tableau de types de 
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registres et dans la pile de types sont representes en 
figure 3b. Ces types comprennent : 

- des identificateurs de classe CB correspondant aux 
classes d'objets specif iques d^finis dans 
1 ' appliquette ; 

- des types de base, tels que short entier code sur p = 
16 bits, intl et int2, p bits les plus et les moins 
significatifs respectivement d'entiers codes sur 2p 
bits par exemple, ou retaddr adresse de retour d'une 
instruction, ainsi que mentionn^ precedemment ; 

- le type null representant les references d'objets nuls. 

En ce qui concerne la relation de sous-typage, on 
indique qu'un type Tl est sous-type d'un type T2 si toute 
valeur valide du type Tl est egalement une valeur valide 
du type T2. Le sous-typage entre identif icateur de classes 
reflete la hierarchie d' heritage entre classes de 
1' appliquette. Sur les autres types, le sous-typage est 
defini par le treillis repr^sente en figure 3b, X 6tant 

gOUg-t:,rp e do tOUS log t>rpoG ot tOUO loo tirpoo Gtant 30U.3 

types de T. 

Le deroulement du processus de verification d'un 
sous-programme constitutif d'une appliquette est le 
suivant, en reference au tableau Tl precedemment 
mentionne. 

Le processus de verification s'effectue 
independamment sur chaque sous -programme de 1 ' appliquette . 
Pour chaque sous-programme, le processus effectue une ou 



plusieurs passes de verification sur les instructions du 
sous -programme considere. Le pseudo-code du processus de 
verification est donne au tableau T2 joint en annexe. 
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Le processus de verification d'un sous-programme 
debute par 1 ' initialisation de la pile des types et du 
tableau des types de registres repr§sentes au tableau Tl, 
cette initialisation refletant I'etat de la machine 
5 virtuelle au debut de 1' execution du sous-programme 
examine . 

La pile des types est initialement vide, le 
pointeur de pile est egal a zero, et les types de 
registres sont initialises avec les types des parametres 

10 du sous -programme illustrant le fait que la machine 
virtuelle passe les parametres de ce sous-programme dans 
ces registres. Les types de registres alloues par le sous- 
programme sont initialises aux types de donnees JL 
illustrant le fait que la machine virtuelle initialise ces 

15 registres ^ 2§ro au debut de 1' execution du sous- 
programme . 

Ensuite, una ou plusieurs passes de verification 
sur les instructions et sur chaque instruction courante Ii 
du sous-programme sont effectuees. 

20 A la fin de la passe de verification mise en ceuvre 

ou d*une succession de passes par exemple, le processus de 
verification determine si les types de registres contenus 
dans le tableau des types de registres representes au 
tableau Tl de 1' annexe ont change pendant la passe de 

25 verification. En 1' absence de changement, la verification 
est terminee et un code de succ6s est renvoye au programme 
principal, lequel permet d'envoyer 1' accuse de reception 

^pos-tfei-f— a — 1-^e-feape — 1-05— du— p-E^o-feoGoie— de— ges-tion— rep>-rese-n-fee- 

en figure 2. 

30 En presence d'une modification du tableau des 

types de registres precite, le processus de verification 
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reitere la passe de verification jusqu'a ce que les types 
de registres contenus dans le tableau des types de 
registres soit stable. 

Le derouleitient proprement dit d'une passe de 
verification effectuee une ou plusieurs fois jusqu'a la 
stabilite du tableau des types de registres sera 
maintenant decrit en liaison avec les figures 3c a 3 j . 

Pour chaque instruction courante Ii, les 
verifications suivantes sont effectuees : 

En liaison avec la figure 3a i I'etape 201, le 
processus de verification determine si 1 ' instruction 
courante Ii est la cible d'une instruction de branchement, 
d'appel de sous-routine ou d'un gestionnaire d' exception, 
ainsi que mentionne precedemment . Cette verification 
s'effectue par examen des instructions de branchement 
contenues dans le code du sous -programme et des 
gestionnaires d' exceptions associes a ce sous-programme. 

En reference a la figure 3c ouverte par I'etape 
201, lorsque 1 ^ instruction courante Ii est la cible d'une 



instruction de branchement, cette condition etant realisee 
par un test 300 designe par Ii=CIB, ce branchement etant 
inconditionnel ou conditionnel, le processus de 
verification s' assure que la pile des types est vide a ce 
point du sous-programme par un test 301. Sur reponse 
positive au test 301, le processus de verification est 
poursuivi par une etape suite de contexte note suite A. 
Sur reponse negative au test 301, la pile des types 
-n-J-e-tan-t— pas— vd-de7--ta— veri-f-ic^^^^^ 

est rejet^e. Get echec est representee par I'etape Echec. 

En reference a la figure 3d ouverte par I'etape 
suite A, lorsque 1 ' instruction courante Ii est la cible 
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d'un appel de sous-routine, cette condition etant realisee 
par un test 304 Ii=CSR, le processus de verification 
verifie en un test 305 que 1 ' instruction precedente Ii-i ne 
continue pas en sequence. Cette verification est realisee 
5 par une etape de test 305 lorsque 1 ' instruction precedente 
constitue un branchement inconditionnel, un retour de 
sous-routine ou une levee d' exception. Le test a 1' etape 
305 est note ainsi : 

li-i = IBinconditionnei/ retour RSR OU levee L-EXCEPT. 

10 Sur reponse negative au test 305, le processus de 

verification echoue en une etape Echec. Au contraire, sur 
reponse positive au test 305, le processus de verification 
reinitialise la pile des types de facon que celle-ci 
cbntienne exactement une entree de type retaddr, adresse 

15 de retour de la sous-routine precitee. Si 1 ' instruction 
courante Ii k 1' etape 304 n'est pas la cible d'un appel de 
sous-routine, le processus de verification est poursuivi 
dans le contexte a 1' etape suite B. 

En reference a la figure 3e, lorsque 1 ' instruction 

20 courante It est la cible d'un gestionnaire d' exceptions, 
cette condition etant realisee par un test 307 note Ii = 
GEM, CEM designant la cible d'un gestionnaire 
d * exceptions, cette condition est realisee par 
1 ' intermediaire d'un test 307, note : 

25 Ii=CEM. 

Le processus, sur reponse positive au test 307 verifie que 
1 ' instruction precedente constitue un branchement 

inconditionnel, un retour de sous-routine ou une levee 

d'exeptions par 1 ' intermediaire d'un test 305 note : 

30 Ii-i=IBinconditionnei/ retour RSR OU levee L-EXCEPT. 
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Sur reponse positive au test 305, le processus de 
verification precede a une reactualisation de la pile des 
types, a une etape 308, par une entree de types des 
exceptions, notee type EXCEPT, 1 • etape 308 etant suivie 
d'une etape de suite de contexte, suite C. Sur reponse 
negative au test 305, le processus de verification echoue 
par 1' etape not§e Echec. Le fragment de programme est 
alors rejete. 

En reference d la figure 3f, iorsque 1 ' instruction 
courante li est la cible d'une pluralite de branchements 
incompatibles, cette condition est r6alis§e par un test 
309, lequel est not6 : 

Ii=XIB incompatibles 
les branchements incompatibles ^tant par exemple un 
branchement inconditionnel et un appel de sous-routine ou 
encore deux gestionnaires d' exceptions differents. Sur 
r6ponse positive au test 309, les branchements etant 
incompatibles, le processus de verification echoue par une 

etape not6e Echec et le fragment de programme est rejet6. 

Sur reponse negative au test 309, le processus de 
verification est poursuivi par une etape notee suite D. Le 
test 309 est ouvert par 1 'etape suite C precedemment 
mentionnee dans la description. 

En reference A la figure 3g, Iorsque 1 ' instruction 
courante Ii n'est la cible d'aucun branchement, cette 
condition 6tant realisee par un test 310 ouvert par la 
suite D precedemment mentionnee, ce test 6tant note 

I-i— 3-?— ei-bies— de— branchemen-t-7- 



3 d^signant le symbole d' existence, 
le processus de verification continue sur reponse negative 
au test 310 par passage k une actualisation de la pile des 
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types a une 6tape 311, l'6tape 311 et la reponse positive 
au test 310 etant suivies d'une etape de suite de contexte 
^ 1' etape 202, decrite precedemment dans la description en 
liaison avec la figure 3a. 
5 Une description plus detaillee de 1' etape de 

verification de I'effet de 1 ' instruction courante sur la 
pile des types a 1' etape 202 precedemment citee sera 
maintenant donnee en liaison avec la figure 3h. 

Selon la figure precitee, cette etape peut 
10 comporter au moins une etape 400 de verification que la 
pile d' execution des types contient au moins autant 
d' entrees que 1 ' instruction courante comporte d'operandes. 
Cette etape de test 400 est not6e : 

Nbep ^ NOpi 

15 oCi Nbep designe le nombre d' entries de la pile des types 
et NOpi designe le nombre d'operandes contenus dans 
1 ' instruction courante. 

Sur reponse positive au test 400, ce test est suivi d'une 
etape 401a de depilement de la pile des types et de 

20 verification 401b que .les types des entrees au sommet de 
la pile sont sous-types des types des operandes de 
1 ' instruction courante precitee. A 1' etape de test 401a, 
les types des operandes de 1 ' instruction i sont notes TOpi 
et les types des entrees au sommet de la pile sont notes 

25 Targs . 

A 1' etape 401b, la verification correspond a une 
verification de la relation de sous-typage Targs sous-type 

deJ^Opi 

Sur reponse negative au test 400 et au test 401b, 
30 le processus de verification echoue, ce qui est illustre 
par I'acc^s A 1' etape Echec. Au contraire sur r6ponse 
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positive au test 401b, le processus de verification est 
poursuivi et consiste a effectuer : 

- Une etape de verification de 1 'existence d'un 
espace memoire suffisant sur la pile des types, pour 
5 proceder a 1 ' empilement des resultats de 1 ' instruction 
courante. Cette etape de verification est realisee par un 
test 402 note : 

Esp-pile ^ Esp-r6sultats 
oCi chaque membre de I'inegalite designe 1' espace memoire 
10 correspondant • 

Sur reponse negative au test 402, le processus de 
verification echoue, ce qui est illustre par 1' etape 
Echec. Au contraire, sur reponse positive au test 402, le 
processus de verification precede alors a 1' empilement des 
15 types de donnees attribuees aux resultats en une etape 
403, 1' empilement etant effectue sur la pile des types de 
donnees attribute a ces resultats. 

A titre d'exemple non limitatif, on indique que 

PQur la mififi en iPiivrp dp la fignre de verification dQ 

20 I'effet de 1 * instruction courante sur la pile des types, 
pour une instruction courante constitute par une 
instruction Java saload correspondant a la lecture d'un 
element entier cod6 sur p = 16 bits dans un tableau 
d'entiers, ce tableau d'entiers etant defini par le 
25 tableau d'entiers et un indice entier dans ce tableau, et 
le resultat par 1' entier lu a cet indice dans ce tableau, 
le processus de verification s' assure que la pile des 
types conlTient au moi"ns deux eXements, que Tes deux 
elements au sommet de la pile des types sont sous-types de 
30 short [ ] respectivement short , precede au processus de 
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depilement et ensuite au processus d' empilement du type de 
donn^es short coinine type du resultat. 

En outre/ en reference a la figure 3i, pour la 
raise en cBUvre de I'etape de verification de I'effet de 
5 1 ' instruction courante sur la pile des types, lorsque 
1 ' instruction courante Ii est una instruction de lecture, 
notee IR, d'un registre d'adresse n, cette condition etant 
realisee par un test 404 note Ii=IRn/ sur reponse positive 
au test 404 precite, le processus de verification consiste 

10 ^ verifier le type de donnees du resultat de cette 
lecture, en une etape 405,^ par consultation de 1' entree n 
du tableau des types de registres, puis a determiner 
I'effet de 1 ' instruction courante Ii sur la pile des types 
par une operation 406a de depilement des entrees de la 

15 pile correspondant aux op6randes de cette instruction 
courante et par empilement 406b du type de donnees de ce 
resultat. Les operandes de 1 ' instruction It sont notes 
OPi. Les etapes 406a et 406b sont suivies d'un retour a la 
suite de contexte suite F, Sur reponse negative au test 

20 404, le processus de verification est poursuivi par la 
suite de contexte suite F. 

En reference a la figure 3j, lorsque 1 ' instruction 
courante Ii est une instruction d'ecriture, notee IW, d'un 
registre d'adresse n, cette condition etant realisee par 

25 un test note Ii=IWm, le processus de verification 
consiste, sur reponse positive au test 4.07, a determiner 
en une etape 408 I'effet de 1 ' instruction courante sur la 

^p.il.e_de.s t_yp.e.s ^e-t_l.e typ.e t_de_l_I_opjer.and.e_e.crLi_t ^dans_l-e_ 

registre d'adresse n, puis, en une etape 409, a remplacer 

30 1' entree du type du tableau des types de registres d 
I'adresse n par le type immediatement superieur au type 
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precedemment stocke et au type t de I'operande ecrit dans 
le registre d*adresse n. L'etape 409 est suivie d'un 
retour a la suite de contexte suite 204. Sur reponse 
negative au test 407, le processus de verification est 
poursuivi par une suite de contexte suite 204. 

A titre d'exemple, lorsque 1 ' instruction courante 
li correspond a I'ecriture d'une valeur de type D dans un 
registre d'adresse 1 et que le type du registre 1 avant 
verification de 1 ' instruction etait C, le type du registre 
1 est remplace par le type object qui est le type 
superieur le plus petit de C et D dans le treillis des 
types represents en figure 3b. 

De meme, A titre d'exemple, lorsque 1 ' instruction 
courante Ii est une lecture d'une instruction aload-0 
consistant ^ empiler le contenu du registre 0 et que 
1' entree 0 du tableau des types de registres est C,. le 
verificateur empile C sur la pile des types. 

Un exeraple de verification d'un sous -programme 

ecrit en environnement Java sera maintenant donne en 

20 liaison avec les tableaux T3 et T4 introduits en annexe. 

Le tableau T3 represente un code JavaCard 
specif ique correspondant au sous -programme Java inclus 
dans ce tableau. 

Le tableau T4 illustre le contenu du tableau des 
25 types de registres et de la pile des types avant la 
verification de chaque instruction. Les contraintes de 
types sur les operandes des di verses instructions sont 
toutes respectees-; — ira — p±i:e — est — vide — ^aussi — ^bren — ap-fes — 
1 ' instruction de branchement 5 a 1 ' instruction 9 
30 symbolisee par. la fleche, qu' avant la cible de branchement 
9 precitee. Le type du registre 1 qui etait initialement ± 
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devient null / la borne superieure de null et de ±, lorsque 
1' instruction 1 de stockage d'une valeur de type null dans 
le registre 1 est examinee, puis devient de type short [], 
la borne superieure du type short [] et du type hull / 

5 lorsque 1 ' instruction 8, stockage d'une valeur de type 
short [] dans le registre 1 est traitee. Le type du 
registre 1 ayant change pendant la premiere passe de 
verification/ une seconde passe est effectuee en repartant 
des types de registres obtenus a la fin de la premiere. 

10 Cette seconde passe de verification reussit tout comme la 
premiere et ne modifie pas les types des registres. Le 
processus de verification se termine done avec succSs. 

Diff6rents exemples de cas d'§chec du processus de 
verification sur quatre exemples de code incorrect seront 

15 maintenant donnas en liaison avec le tableau T5 introduit 
en annexe : 

- Au point a) du tableau T5, le code donne en exemple a 
pour objet de tenter de fabriquer une reference d'objet 
invalide en utilisant un processus arithmetique sur des 

20 pointeurs- II est rejete par la verification des types 

des arguments de 1' instruction 2 sadd, laquelle exige 
que ces deux arguments soient de type short - 

- Aux points b) et c) du tableau TS, le code a pour objet 
de realiser deux tentatives de convertir un entier 

25 quelconque en une reference d'objet. Au point b) , le 

registre 0 est utilis§ ^ la fois avec le type short , 
instruction 0/ et avec le type null, instruction 5. En 

consequenceT — 1-e — ^p-roeess-u-s — de — veri-fi-ea-t-iGn — atferibue — l-e~ 

type T au registre 0 et detecte une erreur de type 

30 lorsque le registre 0 est renvoye comme resultat de 

type object a 1 ' instruction 7. 
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- Au point c) du tableau T5, un ensemble de branchements 
du type "if...then...else..." est utilise pour laisser au 
sommet de la pile un resultat qui est constitue soit 
par un entier soit par une reference d'objet. Le 
processus de verification rejette ce code car il 
d^tecte que la pile n'est pas vide au niveau du 
branchement de 1 ' instruction 5 vers 1 ' instruction 9 
symbolisee par la fleche. 

- Enfin, au point d) du tableau T5, le code contient une 
boucle qui, ^ chaque iteration, a pour effet d'empiler 
un entier de plus au sommet de la pile et de provoquer 
done un d6bordement de la pile apres un certain nombre 
d' iterations. Le processus de verification rejette ce 
code en constatant que la pile n'est pas vide au niveau 
du branchement arriere de 1 ' instruction 8 vers 
1 'instruction 0, symbolise par la fleche de retour, la 
pile n'etant pas vide a un point de branchement. 

Les diff brents exemples donnes prec^demment en 
liaison avec le s tableaux T3. T4 et T5 montrent que 1p 
processus de verification, objet de la presente invention, 
est particuli^rement efficace et qu'il s' applique a des 
appliquettes et en particulier aux sous-programmes de ces 
derni^res, pour lesquelles les conditions de type de pile 
respectivement de caract^re vide de la pile des types 
ant^rieurement et aux instructions de branchement ou de 
cibles de branchement sont satis faites. 

Bien entendu, un tel processus de verification 
-i-mp-l±que t-'-^criture— de — ^codes — dbj&t — s^tl-s-f-ai-sant — a — ces 
criteres, ces codes objet pouvant correspondre au sous- 
programme introduit au tableau T3 precedenuaent mentionne. 
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Toutefois, et afin d' assurer la verification 
d' appliquettes et de sous-programmes d' appliquettes 
existantes qui ne satisfont pas necessairement aux 
criteres de verification du precede objet de la presente 
invention, en particulier pour ce qui concerne les 
appliquettes et les sous-programmes ecrits en 
environnement Java, la presente invention a pour objet 
d'etablir des precedes de transformation de ces 
appliquettes ou sous-programmes en appliquettes ou 
fragments de programme normalises permettant de subir avec 
succes les tests de verification du proced6 de 
verification objet de la presente invention et du 
protocole de gestion mettant en oeuvre un tel proced6. 

Dans ce but, 1' invention a done pour objet la mise 
en oeuvre d'un procede et d'un programme de transformation 
d'un code objet classique constituant une appliquette, ce 
procede et ce programme de transformation pouvant etre mis 
en oeuvre hors d'un syst^me embarque ou d'une carte ^ 
microprocesseur lors de la creation de 1 ' appliquette 
20 consideree. 

Le procede de transformation de code en code 
normalise objet de la presente invention, sera maintenant 
decrit dans le cadre de 1 ' environnement Java a titre 
d'exemple purement illustratif. 
25 Les codes JVM produits par les compilateurs Java 

existants satisfont a differents critdres, lesquels sont 
enonces ci-apres : 

CI — : les — arguments — de — chaque — instruction — apparJ:i.ennent^ 

bien aux types attendus par cette instruction ; 
30 C2 : la pile ne deborde pas ; 
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C'3 : pour chaque instruction de branchement, le type de 
la pile au niveau de ce branchement est le meme 
qu'au niveau des cibles possibles pour ce 
branchement ; 

CM : une valeur de type t ecrite dans un registre en un 
point du code et relue depuis ce mgme registre en un 
autre point du code est toujours relue avec le meme 
type t ; 

La mise en oeuvre du procede de verification objet 
de la presente invention, implique que les criteres C'3 et 
C'4 verifies par le code objet soumis a verification 
soient remplac6s par les criteres C3 et C4 ci-apres : 
C3 : la pile est vide a chaque instruction de branchement 

et ^ chaque cible de branchement ; 
C4 : un meme registre est utilise avec un seul et meme 
type dans tout le code d'un sous-programme. 

En reference aux criteres precites, on indique que 
les compilateurs Java garantissent seulement les criteres 

r^ - ^^ s — ^ ^i fa -'^ ^ s — CJ-3 — — CIA, l e processus — da — verification 

objet de la presente invention et le protocole de gestion 
correspondant garantissent en fait des criteres C3 et C4 
plus contraignants permettant d' assurer la securite 
d' execution et de gestion des appliquettes • 

La notion de normalisation recouvrant la 
transformation des codes en codes normalises peut 
presenter differents aspects, dans la mesure ou le 
remplacement des criteres C'3 et C'4 par les criteres C3 
et C4'; conformement au processus de verification objet de 
la presente invention, peut §tre realise de maniere 
independante pour assurer que la pile est vide ^ chaque 
instruction de branchement et a chaque cible de 
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branchement/ respectivement que les registres ouverts par 
1 ' appliquette sont types, a chaque regis tre ouvert 
correspondant un seul type de donnee attribu6 pour 
1' execution de 1 ' appliquette consideree, ou, au contraire/ 
5 de maniere conjointe, afin de satisfaire a 1' ensemble du 
processus de verification objet de la presente invention. 

Le procede de transformation d'un code objet en 
code objet normalise selon 1' invention sera en consequence 
decrit selon deux modes de mise en cBuvre distincts, un 

10 premier mode de mise en oeuvre correspondant a la 
transformation d'un code objet satisfaisant aux criteres 
CI, C2, C'3, CM en un code objet normalise satisfaisant 
aux criteres CI, C2, C3, CM correspondant k un code 
normalise a instruction de branchement ou cible de 

15 branchement vide, puis, selon un deuxieme mode de 
realisation, dans lequel le code objet classique 
satisfaisant aux memes criteres de depart, est transforme 
en un code objet normalise satisfaisant aux criteres CI, 
C2, C'3, C4 par exemple correspondant a un code normalise 
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faisant appel a des registres types. 






Le premier mode de realisation du procede de 






transformation de code, objet de la presente invention. 






sera maintenant decrit en liaison avec la figure 4a. Dans 






le mode de realisation illustre en figure 4a, le code 
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classique de depart est repute satisfaire aux criteres 






Cl+C2+C'3 et le code normalise obtenu du fait de la 






transformation est repute satisfaire aux criteres 






C1+C2+C3. 






Selon la figure precitee, le procede de 
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transformation consiste, pour chaque instruction courante 



li du code ou du sous -programme, k annoter chaque 
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instruction, en une etape 500, par le type de donn^es de 
la pile avant et aprds 1' execution de cette instruction. 
Les donn^es d' annotation sont notees AIi et sont associees 
par la relation Ii-f^AIi en instruction courante consideree. 
Les donnees d' annotation sont calculees au moyen d'lane 
analyse du flot des donnees relatif a cette instruction. 
Les types de donnees avant et aprds execution de 
1' instruction sont notes tbei et taei respectivement . Le 
calcul des donnees d' annotation par analyse du flot des 
donn6es est un calcul classique connu de I'homme du metier 
et, a ce titre, ne sera pas d§crit. en detail. 

L' operation realisee ii l'§tape 500 est illustree 
au tableau T6 introduit en annexe dans lequel, pour une 
appliquette ou sous-programme d'appliquette comportant 12 
instructions, les donnees d' annotation AIi const ituees par 
les types des registres et les types de la pile sont 
introduites. 

L'6tape 500 pr^citee est alors suivie d'une etape 
500a consistant a positionner 1' index i sur la premiere 
instruction Ii=Ii. L' etape 500a est suivie d'une etape 501 
consistant a detecter, au sein des instructions et de 
chaque instruction courante 1^, 1' existence de 
branchements notes IB ou de cibles de branchement CIB pour 
lesquels la pile d' execution n'est pas vide. Cette 
detection 501 est r6alis6e par un test conduit a partir 
des donnees d' annotation AIi du type des variables de pile 
alloue a chaque instruction courante, le test 4tant not6 
-pour— 1-i-i-ns-t-ruct-i-ori— Gou-ra-n-te— 1 ■ 



Ii est une IB ou CIB et pile(AI)5t vide. 
Sur r§ponse positive au test 501, c'est-a-dire en 
presence d'une detection d'une pile d' execution non vide, 
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le test precite est suivi d'une etape consistant a inserer 
des instructions de transfert des variables de pile de 
part et d' autre de ces branchements IB ou de ces cibles de 
branchement CIB, afin de vider le contenu de la pile 
5 d' execution dans des registres temporaires avant ce 
branchement et de r§tablir la pile d' execution a partir 
des registres temporaires apres ce branchement, L'6tape 
d' insertion est notee 502 sur la figure 4a. Elle est 
suivie d'une etape de test 503 d'atteinte de la derniere 
10 instruction note 

Ii=derniere instruction? 
Sur reponse negative au test 503, une incrementation 504 
i=i+l est effectuee pour passage a 1 ' instruction suivante 
et retour a 1' etape 501. Sur reponse positive au test 503, 

15 une 6tape de Fin est lancee. Sur reponse negative au test 
501, le proced§ de transformation est poursuivi par un 
branchement vers 1' etape 503 en 1' absence d^ insertion 
d' instruction de transfert. La mise en oeuvre du precede de 
transformation d*un code classique en un code normalise a 

"20 instruction de branchement a pile vide Lei que lypiesente 

en figure 4a, permet d'obtenir un code objet normalise 
pour le meme fragment de programme de depart dans lequel 
la pile des variables de pile est vide k chaque 
instruction de branchement et a chaque instruction de 

25 cible de branchement, en 1 ' absence de modification de 
1' execution du fragment de programme. Dans le cas d'un 
environnement Java, les instructions de transfert de 
donnees entre pile et registre sont les instructions load 
et store de la machine virtuelle Java. 

30 En reprenant I'exemple introduit au tableau T6, le 

precede de transformation detecte une cible de branchement 
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oCi la pile n'est pas vide au niveau de 1 ' instruction 9. II 
est done procede a 1' insertion d'une instruction istore 1 
avant 1 ' instruction de branchement 5 qui mene a 
1 ' instruction 9 precitee afin de sauvegarder le contenu de 
5 la pile dans le registre 1 et d' assurer que la pile est 
vide lors du branchement. Symetriquement, 1' insertion 
d'une instruction iload 1 est effectuee prealablement a la 
cible d' instruction 9 pour retablir le contenu de la pile 
identiquement ^ ce qu'il etait avant le branchement. 
10 Finalement, une instruction istore 1 est inseree apres 
1" instruction 8 pour garantir I'equilibre de la pile sur 
les deux chemins qui menent a 1 ' instruction 9. Le resultat 
de la transformation ainsi op6ree en un code normalise est 
represents au tableau T7. 
15 Le deuxieme mode " de realisation du procede de 

transformation objet de la presente invention sera 
maintenant decrit en liaison avec la figure 4b dans le cas 
ou le code objet classique de depart satisfait aux 

criteres Cl+C'4 et le code obiet normalise satisfait aux 

20 criteres C1+C4. 

En reference a la figure 4b precitee, on indique 
que le procede, dans ce mode de realisation, consiste a 
annoter, selon une etape 500 sensiblement identique a 
celle representee en figure 4a, chaque instruction 
courante li par le type de donnees des registres avant et 
apres 1 ' execution de cette instruction. De la m&me 
maniere, les donnees d' annotations Alt sont calculees au 
nioyen— dr'-une— ana±yse— du— fl-ot— de"s— donn-6-^^^ 
instruction. 

30 L'6tape d' annotation 500 est alors suivie d'une 

etape consistant a effectuer une reallocation des 
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registres, etape notee 601, par detection des registres 
d'origine employes avec des types differents, division de 
ces registres d'origine en registres normalises distincts, 
un registre normalise etant alloue a chaque type de 
donn6es utilise. L'6tape 601 est suivie d'une 6tape 602 de 
reactualisation des instructions qui manipulent les 
operandes qui font appel aux registres normalises 
precites. L' etape 602 est suivie d'une etape de suite de 
contexte 302. 

En reference a I'exemple donne au tableau T6, on 
indique que le precede de transformation detecte que le 
registre de rang 0, note rO, est utilise avec les deux 
types object / instructions 0 et 1, et int, instruction 9 
et suivantes. II est alors procede a une division du 
registre d'origine rO en deux registres, le registre 0 
pour I'utilisation des . types object et le registre 1 pour 
les utilisations de type int. Les references au registre 0 
de type int sont alors reecrites en les transformant en 
des references au registre 1, le code normalise obtenu 
20 etant introduit au tableau T8 joint en annexe. 

On note de maniere non limitative que dans 
I'exemple introduit en liaison avec le tableau T8 precite, 
le nouveau registre 1 est utilise a la fois pour la 
normalisation de la pile et pour la creation de registres 
25 types par division du registre 0 en deux registres. 

Le precede de transformation d'un code classique 
en un code normalise a instruction de branchement a pile 

tel q ue decrit en figure 4a sera maintenant decrit de 

maniere plus detailiee dans un mode de realisation 
30 preferentiel non limitatif, en relation avec la figure 5a. 
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Ce mode de realisation concerne I'etape 501 
consistant ^ d^tecter au sein des instructions et de 
chaque instruction courante Ii 1' existence de branchement 
IB respectivement de cible de branchement CIB pour 
5 laquelle la pile n'est pas vide. 

Suite a la determination des instructions cible ou 
la pile n'est pas vide, cette condition etant notee a 
I'etape 504a, Ii pile^tvide, le processus de transformation 
consiste a associer, a I'etape 504a precitee, a ces 
10 instructions un ensemble de nouveaux registres, un par 
emplacement de pile actif au niveau de ces instructions. 
Ainsi, si i designe le rang d'une cible de branchement 
dont le type de pile associee n'est pas vide et est du 
type tpli a tpni avec n > 0, pile non vide, le processus 
15 de transformation alloue n nouveau registres, ri a rn non 
encore utilises et les associe a 1 ' instruction i 
correspondante. Cette operation est realisee a I'etape 
504a. 

■ L'etape 504a est suivie d'une etape 504 consis tant 

a examiner chaque instruction detectee de rang i et a 
discriminer en une etape de test 504 1' existence d'une 
cible de branchement CIB ou d'un branchement IB. L'etape 
504 est representee sous forme d'un test designe par : 

3?CIB,IB et Ii=CIB. 
Dans le cas ou 1 ' instruction de rang i est une 
cible de branchement CIB representee par I'egalite 
precedente, et que la pile des variables de pile au niveau 

-de — ee-ttre — i-n-s-tfrue-ti-on — ^n-'-est — ^pas — ^videT c-'-es-t--^— dtre — en— 

reponse positive au test 504, pour toute instruction 
precedente de rang i-1 constitute par un branchement, une 
levee d' exceptions ou un retour de programme, cette 
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condition est realises a I'etape de test 505 designee 
par : 

li-i = IB, levee EXCEPT, retour Prog. 
instruction d§tect6e de rang i n'est accessible que par 
5 un branchement . Sur r^ponse positive au test 505 precite, 
le processus de transformation consiste a effectuer une 
etape 506 consistant a insurer un ensemble d' instructions 
de chargement du type load a partir de 1' ensemble de 
nouveaux registres antferieurement a 1 ' instruction detectee 
10 de rang i considere. L' operation d* insertion 506 est 
suivie d'une redirection 507 de tous les branchements vers 
1 ' instruction detectee de rang i, vers la premiere 
instruction de chargement load inseree. Les operations 
d' insertion et de redirection sont representees au tableau 
15 T9 joint en annexe. 

Pour toute instruction precedente de rang i-1 
continuant en sequence, c'est-a-dire lorsque 1 ' instruction 
courante de rang i est accessible a la fois par un 
branchement et & partir de 1 ' instruction precedente, cette 

"20 condition 6LanL r6alls6e par le test 508 et symbolisee par 

les relations : 

li-i^Ii 

et 

IB->Ii 

25 le processus de transformation consiste en une fetape 509 a 
inserer un ensemble d' instructions de sauvegarde store 
vers 1* ensemble de nouveaux registres anterieurement S 

1 ' instruction detectee de rang ' i, et un ensem ble 

d' instructions de chargement load a partir de cet ensemble 

30 de nouveaux registres • etape 509 est alors suivie d'une 
etape 510 de redirection de tous les branchements vers 
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1 ' instruction detectee de rang i vers la premiere 
instruction de chargement load inseree. 

Dans le cas ou 1 ' instruction detectee de rang i 
est un branchement vers une instruction deteriuinee, pour 
5 touts instruction detectee de rang i constitute par un 
branchement inconditionnel/ cette condition etant realisee 
par un test 511 note : 

li^IBincondit. 

le processus de transformation tel que represents en 
10 figure 5a consiste a ins6rer a une etape 512, sur reponse 
positive au test 511, anterieurement a 1 ' instruction 
detectee de rang i, une plurality d' instructions de 
sauvegarde store > Le processus de transformation insure 
avant 1 ' instruction i les n instructions store ainsi que 
15 represente en exemple au tableau Til. Les instructions 
store adressent les registres ri a rn, n designant le 
nombre de registres. A chaque nouveau registre est ainsi 
associee 1 ' instruction de sauvegarde. 

Pour toute instruction detectee de rang i 

20 constituee par un branchement conditionnel et pour un 
nombre mOp super ieur a 0 d'operandes manipules par cette 
instruction de branchement conditionnel/ cette condition 
etant realisee par le test 513 note : 

Ii=IBcondit. 

25 avec mOp > 0 

le processus de transformation, en r6ponse positive au 

test 513 precite, consiste a inserer a une etape 514 
ranter i'Burement— a— cette-^rnstructron^det-e^ — une- 

instruction de permutation notee swap_x au sommet de la 
30 pile des variables de pile des mOp operandes de 

1 ' instruction detectee de rang i et des n valeurs 
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suivantes- Cette operation de permutation permet de 
ramener au sornmet de la pile des variables de pile les n 
valeurs a sauvegarder dans 1' ensemble des nouveaux 
registres ri a rn. L'etape 514 est suivie d'une etape 515 
5 consistant a inserer antferieurement a 1 ' instruction de 
rang i un ensemble d' instructions de sauvegarde store vers 
1' ensemble des nouveaux registres ri a rn. L' etape 515 
d' insertion precitee est elle-meme suivie d'une etape 516 
d' insertion posterieurement a 1 ' instruction detectee de 

10 rang i d'un ensemble d' instructions de chargement load a 
partir de 1 'ensemble des nouveaux registres ri i rn- 
L' ensemble des operations d' insertion correspondantes est 
represents au tableau 12 introduit en annexe. 

Pour des raisons de completude et en r§f6rence a 

15 la figure 5a, on indique que, sur reponse negative au test 
504, la poursuite du processus de transformation est 
realisfee par une 6tape de .suite de contexte suite 503, que 
la reponse negative aux tests, 505, 508, 511 et 513 est 
elle-meme suivie d'une poursuite du processus de 

20 transformation par 1 ' intermediaire d'une etape de suite de 
contexte suite 503 et qu'il en est de meme en ce qui 
concerne la poursuite des operations apres les etapes de 
redirection 507 et 510 et d' insertion 512 et 516 
precitees . 

25 Une description plus detaillee du proc§de de 

normalisation et de transformation d'un code objet en un 
code objet normalise faisant appel a des registres types 

^t-el_que ^decri.t ^en fi.gur.e 4b., s.era_maint.enant donnee ^en_ 



liaison avec la figure 5b. Ce mode de realisation concerne 
30 plus particuliSrement un mode de realisation preferentiel 
non limitatif de 1' etape 601 de reallocation des registres 
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par detection des registres d'origine employes avec des 
types diff brents. 

En reference a la figure 5b precitee, on indique 
que I'etape 601 precitee consiste a determiner en une 
5 etape 603 les intervalles de duree de vie notes IDj de 
chaque registre r j . Ces intervalles de duree de vie, 
designes par "live range" ou "webs" en langage anglo- 
saxon, sent definis pour un registre r coirane un ensemble 
maximal de traces partielles tel que le registre r est 

10 vivant en tous points de ces traces- Pour une definition 
plus d6taillee de ces notions^ on pourra utilement se 
reporter a I'ouvrage edite par Steven S. MUCHNICK intitul6 
"Advanced Compiler Design and Implementation", Section 
16.3, Morgan KAUFMANN, 1997. L' etape 603 est designee par 

15 la relation : 

IDj<->rj 

selon laquelle a chaque registre rj est associe un 
intervalle de duree de vie IDj correspondant . 
L' etape 603 precitee est suivie d^une etape 604 

20 consistant a determiner, ^ I'etape 604, le type de donnees 
principal, note tpj, de chaque intervalle de duree de vie 
IDj. Le type principal d'un intervalle de duree de vie 
IDj, pour un registre rj, est defini par la borne 
sup^rieure des types de donnee stock6s dans ce registre rj 

25 par les instruction de sauvegarde store appartenant a 
1' intervalle de dur6e de vie pr6cit6. 

L'6tape 604 est elle-meme suivie d'une etape 605 
consTstant — ^a — ^etrab'trr^un — graph'e — d"'~i:nferfe"r'en"c"eB — entree — l"^"s~" 
intervalles de dur6e de vie precedemment definis aux 

30 etapes 603 et 604, ce graphe d' interferences consistant en 
un graphe non oriente dont chaque sommet est constitue par 
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un intervalle de duree de vie et dont les arcs, notes 
siji,j2 sur la figure 5b, entre deux sommets IDji et IDj2, 
existent si un sommet contient une instruction de 
sauvegarde adressee au registre de 1' autre sommet ou 
5 r§ciproquement . Sur la figure 5b, la construction du 
graphe d' interferences est representee symbol iquement, 
cette construction pouvant etre realisfee a partir de 
techniques de calcul connues de I'horome du metier. Pour 
une description plus detaill6e de la construction de ce 
10 type de graphe, on pourra utilement se reporter a 
I'ouvrage publie par Alfred V.AHO, Ravi SETHI et Jeffrey 
D. ULLMAN intitule "Compilers : principles ^ techniqueSr 
and tools", Addison-Wesley 1986, section 9.7. 

Suite a I'etape 605, le procede de normalisation 
15 tel que represents en figure 5b consiste a traduire a une 
etape 606 I'unicite d'un type de donnee alloue a chaque 
registre rj dans le graphe d' interferences en ajoutant des 
arcs entre toutes paires de sommets du graphe 
d' interferences tant que deux sommets d'une paire de 

-2cr soi t uiieLs — n'ont — pa3 — i-e — iu6me — type — dn — doiixi6es — principal 

associe. On comprend que la traduction du caractere 
d'unicite d'un type de donnee alloue a chaque registre 
correspond bien entendu a la traduction et a la prise en 
compte du critere C4 dans le graphe d * interferences, 
25 critere mentionne precedemment dans la description. 
L' etape 606 precitee est alors suivie d'une etape 607 dans 
laquelle une instanciation du graphe d' interferences est 
effectuee, instanciation plus communement designee par 
etape de coloriage du graphe d' interferences selon les 
30 techniques habituelles. Au cours de 1' etape 607, le 
processus de transformation attribue a chaque intervalle 
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de duree de vie IDjk un niim§ro de registre rk de telle 
maniere que deux intervalles adjacents dans le graphe 
d' interferences recoivent des numeros de registres 
differents. 

5 Cette operation peut etre realisee a partir de 

tout processus adapte* A titre d'exeraple non limitatif, on 
indique qu'un processus preferentiel peut consister : 

a) a choisir un sominet de degre minimal dans le graphe 
d' interferences, le degre minimal etant defini comme 

10 un nombre de sommets adjacents minimal/ et de le 

retirer du graphe, Cette etape peut etre repetee 
jusqu'a ce que le graphe soit vide. 

b) Chaque sommet precedemment retire est reintroduit dans 
le graphe d' interferences dans I'ordre inverse de leur 

15 retrait, le dernier enleve 6tant le premier 

reintroduit et successivement dans l^ordre inverse de 
I'ordre de retrait. Ainsi, a chaque sommet 
reintroduit, peut etre attribue le plus petit numero 

' de registre qui est different des nxameros attribues a 

20 tous les sommets adjacents. 

Enfin, par 1' etape 602, representee en figure 4b, le 
processus de transformation et de reallocation reecrit les 
instructions d^acces aux registres figurant dans le code 
du sous-programme de 1 ' appliquette consideree. Un acc^s ^ 
25 un registre donne dans I'intervalle de durfee de vie 
correspondant est remplace par un acces A un registre 
different dont le num§ro a et§ attribue pendant la phase 

d-^i-ns-fea-nG-i-a-t-i-on— encore— desi-gnee—pa-j^ 

Une description plus detaillee d'un systeme 
30 informatique embarque permettant la mise en oeuvre du 
protocole de gestion et du processus de verification d'un 
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fragment de programme ou appliquette conforme k I'objet de 
la presente invention et d'un systeme de developpement 
d'une appliquette sera maintenant donnee en liaison avec 
la figure 6. 

En ce qui concerne le systeme embarque 
correspondant portant la reference 10, on rappelle que ce 
systeme embarque est un systeme du type reprogrammable 
comportant les elements essentiels tels que representes en 
figure lb. Le systeme embarque precite est repute 
interconnecte a un terminal par une liaison serie, le 
terminal etant lui-meme relie par exemple par 
1 ' intermediaire d'un reseau local, le cas §cheant d'un 
r6seau lointain, 4 un ordinateur de developpement de 
1' appliquette portant la reference 20. Sur le systdme 
embarque 10 fonctionne un programme principal qui lit et 
execute les commandes envoyees sur la liaison serie par le 
terminal. En outre, les commandes standard pour une carte 
a microprocesseur, telles que par exemple les commandes 
standard du protocole ISO 7816, peuvent etre mises en 
20 oeuvre, le programme principal reconnaissant de plus deux 
commandes supplementaires, I'une pour le telechargement 
d'une appliquette, et 1' autre pour la selection d'une 
appliquette prealablement chargee sur la carte a 
microprocesseur . 

25 Conformement a I'objet de la presente invention, 

la structure du programme principal est realisee de 
maniere a comporter au moins un module de programme de 

ges-fei-on — e-t — de — v-er-if-ication — d~un — fragment — de — ^programme- 

t^lecharge suivant le protocole de gestion d'un fragment 

30 de programme tel6charge pr6cedemment decrit dans la 
description en liaison avec la figure 2. 
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En outre, le module de programme comporte 
6galement un module de sous-programme de verification d'un 
fragment de programme tetl6charge suivant le procede de 
verification tel que decrit precedemment dans la 
description en liaison avec les figures 3a a 3 j , 

Dans ce but, la structure des memoires, en 
particulier de la memoire permanente non inscriptible, 
memoire ROM, est modifiee de maniere a comporter 
notamment, outre le programme principal, un module 17 de 
gestion de protocole et de verification, ainsi que 
mentionne precedemment. Enfin, en ce qui concerne la 
memoire non volatile reinscriptible de type EEPROM, celle- 
ci comporte avantageusement un repertoire d* appliquettes, 
note 18, permettant la mise en ceuvre du protocole de 
gestion et du processus de verification objets de la 
present e invention • 

En reference ^ la meme figure 6, on indique que le 
systeme de d6veloppement de 1 ' appliquette conforme a 
1' objet de la presente invention, permettant en fait la 
transformation d'un code objet classique ainsi que 
mentionn6 precedemment dans la description et satisfaisant 
aux criteres C1+C2+C'3+CM dans le cadre de 
1 ' environnement Java en un code objet normalise pour le 
meme fragment de programme comprend, associe a un 
compilateur classique Java 21, un module de transformation 
de code, note 22, lequel procede a la transformation de 
code en code normalise selon le premier et le deuxi^me 

mode de i^ea-l-i-sat-ion ^precedemment dee-ri-ts dans ta— 

description en liaison avec les figures 4a, 4b et 5a, 5b. 
On comprend en effet que, d'une part, la normalisation du 
code objet d'origine en un code objet normalise a 



53 



instruction de branchement a pile vide et en un code 
normalise faisant appel a des registres types, d' autre 
part, ainsi que mentionne precedemment dans la 
description, permet de satis f aire aux crit^res de 
5 verification C3 et C4 imposes par le procede de 
verification objet de la pr§sente invention. 

Le module de transformation de code 22 est suivi 
d'un convert isseur JavaCard 23, lequel permet d' assurer la 
transmission par un reseau distant ou local vers le 

10 terminal et, par 1 ' intermediaire de la liaison serie, vers 
la carte a microprocesseur 10* Ainsi, le systeme de 
developpement de 1 ' appliquette 20 represents en figure 6 
permet de transformer les fichiers de classe compiles 
produits par le compilateur Java 21 a partir des codes 

15 source Java de 1 ' appliquette en des fichiers de classe 
equivalents mais qui respectent les contraintes 
suppl6mentaires C3, C4 imposees par le protocole de 
gestion et le module de verification 17 embarqu6s sur la 
carte a microprocesseur 10. Ces fichiers de classe 
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transtormes sont convertis en une appliquette 






teiechargeable sur la carte par le convertisseur JavaCard 


• 




standard 23. 






Differents elements particulierement remarquables 






de 1' ensemble des elements du protocole, des precedes et 




25 


des systemes objets de la presente invention, seront 






maintenant donnes a titre indicatif. 






Vis-a-vis des processus de verification de I'art 






anterieur tels que mentio.nnes dans 1 ' introduction a la 






description, le procede de verification objet de la 
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presente invention apparalt remarquable en ce qu'il 



concentre 1' effort de verification sur les proprietes de 
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typage des operandes qui sont essentielles a la securite 
de 1' execution de chaque appliquette, c'est-a-dire du 
respect des contraintes de type associees ^ chaque 
instruction et absence de d6bordement de pile* D'autres 
verifications n' apparaissent pas essentielles en termes de 
sfecurite, en particulier la verification que le code 
initialise correctement chaque registre avant de le lire 
pour la premiere fois. Le procede de verification objet de 
la presente invention opere au contraire par 
initialisation a zero de tous les registres a partir de la 
machine virtuelle lors de 1 ' initialisation de la methode 
afin de garantir que la lecture d"un registre non 
initialise ne peut compromettre la securite de la carte. 

En outre, 1' exigence imposee par le procede de 
verification objet de la presente invention selon laquelle 
la pile doit etre vide a chaque instruction de branchement 
ou de cible de branchement, garantit que la pile est dans 
le m&me etat, vide, apr^s execution du branchement et 
avant execution de 1 ^ instruction a laquelle le programme 
s'est branche. Ce mode operatoire garantit que la pile est 
dans un etat coherent, quel que soit le chemin d' execution 
suivi a travers le code du sous-programme ou de 
1 'appliquette considere. La coherence de la pile est ainsi 
garantie, meme en presence de branchement ou de cible de 
25 branchement. Contrairement aux precedes et aux syst^mes de 
I'art anterieur, dans lesquels il est necessaire de 
conserver en memoire vive le type de la pile a chaque 
eibl-e— de — ^branchement-, — ee — qui — ^neeess-i-te— une— quan-ti-te — de- 
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m6moire vive proportionnelle a TpxNb, produit de la taille 
maximale de pile d' execution utilisee et du nombre de 
cibles de branchement dans le code, le precede de 
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verification, objet de la presente invention, n'a besoin 
que du type de la pile d' execution lors de 1 ' instruction 
en cours de verification et il ne conserve pas en memoire 
le type de cette pile a d'autres points du code. En 
5 consequence, le precede objet de 1' invention se contente 
d'une quantite de m6moire vive proportionnelle a Tp mais 
independante de Nb, et par consequent de la longueur du 
code du sous-programme ou de 1 ' appliquette . 

L' exigence selon le critere C4, selon lequel un 

10 registre donn6 doit §tre utilise avec un seul et meme type 
dans tout le code d'un sous-programme, garantit que le 
code precite n' utilise pas un registre de maniere 
incoherente, par exemple en y ecrivant un entier short a 
un point du programme et en le relisant comme une 

15 reference d* objet a un autre point du programme, 

Dans les processus de verification decrits dans 
I'art anterieur, en particulier dans la specification Java 
intitulee "The Java Virtual Machine Specification" editfee 
par Tim LINDHOLM et Frank YELLIN, d6ja citee, pour 

-20 garantir la cohfexencbi dk^s uLilisdLiuub piecitees a travers 

les instructions de branchement, il est necessaire de 
conserver en memoire vive une copie du tableau des types 
de registres a chaque cible de branchement. Cette 
operation necessite une quantite de memoire vive 

25 proportionnelle a TrXNb ou Tr designe le nombre de 
registres utilises par le sous-programme et Nb le nombre 
de cibles de branchement dans le code de ce sous- 
programme . 

Au contraire, le processus de verification objet 
30 de la presente invention, op6re sur un tableau global de 
types de registres en 1' absence de conservation en memoire 
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Vive de copie a differents points du code. En consequence, 
la m6moire vive necessaire pour realiser le processus de 
verification est proportionnelle a mais independante de 
Nb et done de la longueur du code du sous-programme 
considere. 

La contrainte selon laquelle un registre donn6 est 
utilise avec le meme type en tous points, c'est-a-dire en 
toute instruction du code consid6re, simplifie 
sensiblement et de maniSre significative la verification 
des sous-programmes. Au contraire, dans les processus de 
verification de 1 ' art anterieur, en 1' absence d'une telle 
contrainte, le processus de verification doit etablir que 
les sous -programmes respectent une discipline de pile 
stricte et doit verifier le corps des sous-programmes de 
manidre polymorphe en ce qui concerne le type de certains 
registres . 

En conclusion, le processus de verification objet 
de la presente invention vis-a-vis des techniques de 1 ' art 
anterieur permet, d'une part, de reduire la taille du code 
du programme permettant de conduire le proced^ de 
verification, et, d' autre part, de reduire la consommation 
de m^moire vive lors des operations de verification, le 
degre de complexite etant de la forme ©(Tp+P^) dans le cas 
du processus de verification objet de la presente 
invention, au lieu de (O (Tp+Tr) xNb) pour ce qui concerne 
les processus de verification de I'art anterieur, en 
offrant toutefois les memes garanties vis-a-vis de la 

-s-fir^efee-de— 1-^ex-ecu-t-ion— du~eode— ve^^^ — — 

Enfin, le processus de transformation d'un code 
classique d'origine en un code normalise est realise par 
transformation localis^e du code en 1 * absence de 
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transmission d' informations supplementaires a I'organe 
verif icateur, c' est-S-dire a la carte a microprocesseur ou 
au systeme informatique embarque. 

En ce qui concerne le proced§ de reallocation des 
5 registres tel que decrit en figures 4b et 5b, ce procede 
se distingue des precedes connus de I'art anterieur 
decrits notamment par le brevet US 4,571,678 et par le 
brevet US 5,249,295, par le fait : 

que la reallocation de registre assure qu'un meme 
10 registre ne peut etre attribue a deux intervalles 

possedant des types principaux differents, ce qui 
garantit ainsi qu'un registre donne est utilise avec le 
meme type dans tout le code ; et 

que les algorithmes deallocations de registres 
15 existants et d6crits dans les documents prfecites 

supposent un nombre fixe de registres et tentent de 
minimiser les transferts d6sign6s par "spills'' en 
langage anglo-saxon, entre registres et pile, alors que 
la reallocation des registres conformement ^ I'objet de 
la presente invention opere dans un cadre ou le nombre 
total de registres est variable, en consequence de quoi 
il n'y a pas lieu d'effectuer des transferts entre 
registres et piles alors qu'un processus de 
minimisation du nombre total de registres est mis en 
oeuvre . 
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ANNEXES 

TABLEAU Tl 



Code de la methode 
en cours de verification 



aload 0 
aload 1 
sconst 3 
saload 
putfield C.f 



" Pointeur sur Tinstruction 
en cours de verification 



return 



reg2 
regl 
regO 



short n 
C 



r 

1 






Pointeur de 
pile de types 


short 




short CD 




C 



Tableau de types de registres Pile de types 
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TABI.EAU T2 

PSEUDO-CODE DU MODULE VERIFICATEUR 



Variables globales utilis6es: 

Tr nombre de registres declare par la m6thode courante 

Tp taille maximaie de pile declaree par la methode courante 

tr[Tr] tableau de types de registres (402 dans la figure 4) 

tp[Tp] type de pile (403 dans la figure 4) 

pp pointeur de pile (404 dans la figure 4) 

chg drapeau indiquant si tr a change 

Initialiser pp ^ 0 

Initialiser tp[0] ... tp[n - 1] a partir des types des n arguments de la methode 
Initialiser tp[n] ... tp[Tr - I] a ± 
Initialiser chg a vrai 
Tant que chg est vrai: 
Remettre chg a faux 

Se positionner sur la premiere instruction de la methode 
Tant que la fin.de la methode n*est pas atteinte: 

Si 1' instruction courante est la cible d'une instruction de branchement: 

Si pp#0, echec de la verification 
Si 1' instruction courante est la cible d'un appel de sous-routine: 

Si 1 'instruction precedente continue en sequence, echec 

Prendre tp[0] ^ retaddr et pp -f- 1 
Si 1 'instruction courainte est un gestionnaire d' exceptions de classe C: 

Si 1' instruction precedente continue en sequence, echec 

Faire fp(0] r- C et pp 1 
Si I ' insiiuuuiou cumaiiHj tisi: uuh cibl e d e a o rtes dif f oron-GOSi 

Echec de la verification 
Determiner les types ai,...,an des arguments de I'instruction 
Si pp<n, echec (debordement de pile) 
Po\ir t = 1, .... n: 

Si tplpp — n — t — 1] n'est pas sous -type de a,*, echec 
Faire pp r- pp — n 

Determiner les types ri,...,rm des resultats de 1' instruction 
Si pp'^m>Tp, echec (debordement de pile) 
Pour i = 1, . . . , m , faire tp\pp -r i - 1] <- r,- 
Faire pp pp-rm 

Si 1 'instruction courante est une ecriture dans un registre r: 
Determiner le type t de la valeur ecrite dans le registre 
Faire tr[r] borne infirieure{t, tr[r]) 
Si~tr(r) a cKange , faire cfig ^= vrai 



Si 1 'instruction courainte est un branchement: 

Si pp7=0, echec de la verification 
Avancer a la prochaine instruction 
Renvoyer un code de succes de la verification 
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TABLEAU T3 



static short □ methCshort □ tableau) 
short n resultat = null; 

if (tableau. length >- 2) resultat = tableau - 
return tableau; 

> 



TABI.EAU T4 



Premiere iteration sur le code de la methode: 





Code de la methode 


0 


aconst.null 


1 : 


astore 1 


2 : 


aload 0 


3 : 


arraylength 


4 : 


sconst 2 


5 : 


if.scmplt 9 — 


7 : 


aload 0 


8 : 


astore 1 


9 : 


aload 1 p< 


10 : 


are turn 



Tableau des types des registre s Type de la pile 

• i rO: short U | rl: J, | ( 

' |r0: short U | rl: X | | null | 

' jrO: short U | rl : 1^011 | 

-IrO: short U | rl: nuirH ( short [] I 



short 



• (rO: shorty | rl: null | 

- [rO: short U j rl: nuI3~| | short \ short 
♦ |rQ: short U | rl: n{IIl~] | 

• |ru: snort U | ri: nulF ^ — | short C] [ 

• jrO: shortUirl: shoTnT] | 

' I rO : ^short LJ I rl : short [] | | short [] | 



Seconde iteration sur le code de la methode: 



0 
1 

2 

3 
4 

-5- 



9 
10 



aconst.null 


■ |rO: shortGIrl: short TT] 


astore 1 


|rO: shortCJirl: short [j | 


aload 0 


••■• — ••I rO: short[j|rl: short fl J 


arraylength 


ko: ShortUirl: short CT) 


sconst 2 


Uu: Short U |rl: short H J 

.^-i^^^^|_rO.;_short-[J-|--rl-:_shor-t-g-|- 


it.scmplt 9 — 
aload 0 


"^••••LrO: shortU|rl: short □ | 


astore 1 


j---|rO: shortUjrl: short CF) 


aload 1 


••'-/•-|rO: ShortUjrl: short H J 


1 are turn 


U^- short LJ 1 rl: short f] | 



short ^ 



-s^hort- 
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TABLEAU T5 



(a) Violation des contraintes de types sur les arguments d'une instruction: 



0 : 


aload 0 




1 : 


sconst 1 




2 : 


sadd 




3 : 


areturn 





rO: Object 
rO: Object 



Object 



rO: Object | | Object j short' 



Erreur: le type de la pile ne correspond pas 
& ce qu'attend Tinstruction (short, short) 



(b) Utilisation incoherente d'un registre: 



sload 0 




ifeq 6 — 




aconst.null 




astore 0 


± 


aload 0 




areturn 





rO : short 



rO : short 



rO : short 



rO: short 



rO: T 



rO: T 



I short I 



null 



Erreur: le type de la pile ne correspond pas 
k ce qu'attend Tinstruction (Object) 



(c) Branchements introduisant des incoherences au niveau de la pile: 



sload 0 




ifeq 8 - 




sconst 1 




goto 9 - 




aconst.null 


areturn 



rO : short | | 



1 rO: 


short 1 


1 short 1 


1 rO: 


short 1 


1 


1 rO: 


short 1 


1 short 1 



Erreur: pile non vide a un point de branchement 



(d) Debordement de pile d rinterieur d'une boucle: 



0 

S 
11 



sload 0 



ifeq 11 



j5.const_l_ 



sine 0 -1 



goto 0 



return 




rO ; short | 

rO: short | 

I rO: short | 

I rO: short f 

rO : short | 



short 



short I 



short 



Erreur: pile non vide a un point de branchement 
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TABLEAU T6 



(a) Code initial de la methode, annote par les types des registres et de la pile: 

I Object I 



0 : 


aload 0 


1 : 


if null 8 - 


4 : 


iconst 1 


5 : 


goto 9 — 


8 : 


iconst 0 


9 : 


ineg 


10 : 


istore 0 


11 : 


iload 0 


12 : 


ireturn 



♦ | rO: Object 

• | rO: Object 

' I rO: Object 

• | rO: Object 

• | rO: Object 

• | rO: Object 



rO; 



lect 



rO : int 
rO: int 



int 



int I 



int 



xnt 



TABLEAU T7 



(b) Code de la methode apres normalisation de la pile au niveau du branchement 5 -^^ 9: 



0 
1 
4 

4' 
5 
8 

8* 

8" 
9 

10 
-1-1- 

12 



aload 0 



ifnull 8 



iconst 1 



istore 1 



goto 8" 



iconst 0 



istore 1 



iload 1 



ineg 



istore 0 

-i-load"0— 



ireturn 



♦ | rO: Object 



rl: X 



rO: Object 



rl: ± 



rO: Object [ 



rl: 1. 



rO: Object | rl : ± 




rO: Object | rl: int 



rO: Object | rl: int 



rO: Object 



rO : int 



rl: J. 



rO: Object | rl: int 



rO: Object | rl: int 



rO: Object | rl: int 



rl: int 



rO: int | rl: int 



Object) 



mt 



mt 



mt 



mt 



mt 
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TABUEAUT8 



(c) Code de la methode apns reallocation des registres 



0 
1 
4 
4" 
3 
8 
8" 
8" 
9 

10 
11 
12 





1 rO: Object | rl: X | 


aload 0 


1 rO: Object | rl: X | 


ifnull 8 - 


. -1 rO: Object | rl: X | 


iconst 1 




. .| rO: Object | rl: X | 


istore 1 




• •( rO: Object | rl: int | 


goto 8" - 




•"1 rO: Object | rl: int | 


iconst 0 




.--| rO: Object | rl: X | 


istore 1 




• --'1 rO: Object | rl: int | 


iload 1 






1 rO: Object | rl : int 1 


istore 1 


1 rO: Object | rl: int | 


iload 1 




ireturn 





Object! 



int 



int 



int 



int 



int 



TABLEAU T9 



(a) able de branchement, instruction precedente ne continuant pas en sequence, 
Brancbement - - Branchement 



instr. Doa seq. 



instruction i 



etat de la pile 

Em 



Normalisation 



instr. aon seq. 



load ri 



load r o 



etat de la pile 

I 

—mi — 
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TABLEAU TIO 



(b) able de branchement, instruction precedente continuant en sequence: 



Branchement 



instr. seq. 



instruction i 



Branchement 



EE 



Normalisation 



instr. seq. 



store ro 



store Tj 



load ri 



load r2 



instruction i 



EE 

E 
I 

0 

Eg 



TABLEAU Til 



(c) Branchement inconditionnel sans arguments: 

Normalisation 



X 

Cible 



goto 



EI] 



store rj 



store rx 



goto 



Gible 



TABLEAU T12 



(d) Branchement conditionnel a un argument: 



Cible 



if eq 



Normalisation 



{aJF\ 



Cible 



swap.x 2,1 



store r ? 
store ri 

if eq 
load ri 
load rj 



[£] 

I 
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REVENDICATIONS 
1. Protocole de gestion d'un fragment de programme 
telecharge sur un systdme embarque reprogrammable, tel 
qu'une carte ^ microprocesseur munie d'une memoire 
5 r6inscriptible, ledit fragment de programme etant 
constitu6 par un code objet, suite d' instructions, 
executable par le microprocesseur du syst6me embarque par 
1' intermediaire d'une machine virtuelle munie d'une pile 
d' execution et de registres ou variables locales 
10 manipulees par ces instructions et permettant 
d' interpreter ce code objet, ledit systeme embarque §tant 
interconnecte a un terminal, caracterise en ce que ce 
protocole consiste au moins, au niveau dudit systeme 
embarque : 

X5 a) a detecter une commande de telechargement de ce 
fragment de programme ; et sur reponse positive a 
cette etape consistant a detecter une commande de 
telechargement, 

b) a lire le code objet constitutif de ce fragment^ de 
"20 progi^amme el ^ iueiuuiiser — t e mporQircmont co cod e objet 

dans ladite memoire reinscriptible ; 

c) a soumettre 1' ensemble du code objet memorise 
temporairement a un processus de verification 
instruction par instruction, ce processus de 

25 verification consistant au moins en une 6tape 

d' initialisation de la pile des types et du tableau 
des types de registres, representant I'etat de ladite 
machine virtuelle au debut de 1' execution du code 
objet memorise temporairement et en une succession 

30 d'etapes de verification instruction par instruction, 

par discrimination de 1' existence, pour chaque 
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instruction courante, d'une cible, cible d' instruction 
de branchement, cible d'un appel d'un gestionnaire 
d* exceptions ou cible d'un appel de sous-routine et 
par une verification et une actualisation de l^effet 
5 de ladite instruction courante sur la pile des types 

et sur le tableau des types de registres, et, dans le 
cas d'une verification reussie dudit code objet, 

d) a enregistrer le fragment de programme telecharge dans 
un repertoire de fragments de programmes disponibles, 

10 et 

e) a renvoyer audit lecteur un - accuse de reception 
positif ; et, dans le cas d*une verification non 
reussie dudit code objet, 

f) k effacer le fragment de programme enregistr6 
15 momentanement, en 1' absence d' enregistrement de ce 

dernier dans ledit repertoire de fragments de 
programmes disponibles, et 

g) a adresser audit lecteur un code d'erreur. 

2. Protocole selon la revendication 1, caracterise 
20 en ce que, sur reponse negative a ladite etape a) 
consistant a detecter une commande de telechargement, 
celui-ci consiste : 

b') a detecter une commande de selection d'un fragment de 
programme disponible dans un repertoire de fragments 

25 de programmes ; et, sur reponse positive a cette etape 

consistant ^ detecter une commande de selection d'un 
fragment de programme disponible ; 

cM a a pp eler ledit fra gm ent d e programme dlsp_onibl.e_ 



selectionne ; 

30 dM a executer ledit fragment de programme disponible 
appele par 1 ' intermediaire de la machine virtuelle, en 



10 
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1' absence de toute verification dynamique de types de 
variables, des droits d'acces'aux objets manipules par 
le fragment de programme disponible appelfe, du 
debordement de la pile d' execution lors de 1' execution 
de chaque instruction, et, sur reponse negative a 
cette 6tape consistant a detecter une commande de 
selection d'un fragment de programme disponible, 
e') a procSder au traitement des commandes standards du 
systeme embarque- 

3, Procede de verification d'un fragment de 
programme telecharge ' sur un systeme embarque 
reprogrammable, tel qu'une carte a microprocesseur munie 
d'une memoire reinscriptible, ledit fragment de programme 
6tant constitue par un code objet et comportant au moins 
15 un sous-programme, suite d' instructions, executable par le 
microprocesseur du systeme embarque par 1 ' intermediaire 
d'une machine virtuelle munie d'une pile d' execution et de 
registres d'operandes manipules par ces instructions et 
permettant d' interpreter ce code objet, ledit systeme 
"20 embarque 6tant interconnecte a un juecteur, carart^rxH^— err 
ce que ledit procede consiste, suite A la detection d'une 
commande de telechargement et a la memorisation dudit code 
objet constitutif de ce fragment de programme dans ladite 
memoire reinscriptible, pour chaque sous-programme : 
25 a) a effectuer une etape d' initialisation de la pile des 
types et du tableau des types de registres par des 
donnees representant I'etat de la machine virtuelle au 
debu t de 1' execution du code objet memorise 



temper air ement ; 

30 3) a effectuer une verification dudit code objet memorise 
temporairement instruction par instruction, par 
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discrimination de 1' existence, pour chaque instruction 
courante, d'une cible, cible d* instruction de 
branchement, cible d'un appel d'un gestionnaire 
d' exceptions ou cible d'un appel de sous-routine ; 
5 y) a effectuer une verification et une actualisation de 
I'effet de ladite instruction courante sur les types 
de donnees de ladite pile des types et dudit tableau 
des types de regis tres, en fonction de 1' existence 
d*une cible d' instruction de branchement, d'une cible 

10 d'un appel de sous-routine ou d'une cible d'un appel 

de gestionnaire d' exceptions, ladite verification 
etant reussie lorsque le tableau des types de 
registres n'est pas modifie au cours d'une 
verification de toutes les instructions et le 

15 processus de verification etant poursuivi instruction 
par instruction jusqu'a ce que le tableau des types de 
registres soit stable, en 1 'absence de modification, 
le processus de verification etant interrompu sinon. 
. 4. Precede de verification selon la revendication 

20 3, caracterise en ce que les types de variables manipulees 
au cours du processus de verification comprennent au 
mo ins : 

des identif icateurs de classes correspondant aux 
classes d'objets d6finies dans le fragment de 
25 programme ; 

des types de variables numeriques comportant au moins 
un type short , entier code sur p bits, et un type 
re"taddr d'^re~s"s~e de retour d'Hne ^instTuc^t~i"on — de — saut~" 
JSR ; 

30 - un type null relatif a des references d'objets nulles ; 
un type object relatif aux objets ; 



m 
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- un premier type sp6cifique ±, repr^sentant 
1' intersection de tous les types et. correspondant a la 
valeur 0, nil ; 

- un deuxieme type specif ique T, repr^sentant 1 'union de 
5 tous les types et correspondant ^ tout type de valeur. 

5. Proc6d6 selon la revendication 4, caracteris§ 
en ce que 1' ensemble desdits types de variables verifie 
una relation de sous-typage : 

ob j ect e Tr- 
io short , retaddr e T; 

1 e null / short , retaddr . 

6. Proc6d6 selon I'une des revendications 3^5, 
caract^rise en ce que lorsque ladite instruction courante 
est la cible d'une instruction de branchement, ledit 

15 precede de verification consiste ^ vferifier que la pile 
des types est vide, le processus de verification etant 
poursuivi pour 1 ' instruction suivante dans le cas d'une 
verification positive, et, le processus de verification 
CChouant et 1° fi-agmt^ni- Hp> programme etant reiete sinon. 

20 7. Procede selon I'une des revendications 3a 6, 

caract§ris6 en ce que lorsque ladite instruction courante 
est la cible d'un appel de sous-routine, ledit processus 
de verification verifie que 1 ' instruction pr^c^dente 
constitue un branchement inconditionnel, un retour de 

25 sous-routine ou une levee d' exception, ledit processus de 
verification, en cas de verification positive, procedant S 
une reactualisation de la pile des types de variables par 
line entite de type retadcir ; aciresse de retour d^~~la~sou-s^ 
routine, et, le processus de verification echouant et le 

30 fragment de programme etant rejete sinon. 
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8. Precede selon I'une des revendications 3^7, 
caracterise en ce que lorsque 1 ' instruction courante est 
la cible d'un gestionnaire d' exceptions, ledit processus 
de verification verifie que 1 ' instruction precedente 

5 constitue un branchement inconditionnel, un retour de 
sous-routine ou une levee d' exception, ledit processus de 
verification, en cas de verification positive, procedant a 
une reactualisation de la pile des types par une entree du 
type des exceptions, et, le processus de verification 
10 echouant et le fragment de programme etant rejete sinon. 

9. Precede selon I'une des revendications 3 a 8, 
caracteris§ en ce que lorsque 1 ' instruction courante est 
la cible d'une pluralite de branchements incompatibles, le 
processus de verification 6choue et le fragment de 

15 programme est rejete. 

10. Precede selon I'une des revendications 3^9, 
caracterise en ce que lorsque 1 ' instruction courante n'est 
la cible d'aucun branchement, le processus de verification 
continue par passage a une reactualisation de la pile des 

20 types - 

11. Precede selon I'une des revendications 3 a 10, 
caracterise en ce que 1 ' etape de verification de I'effet 
de 1 ' instruction courante sur la pile des types comporte 
au mo ins : 

25 - une etape de verification que la pile d' execution des 
types contient au moins autant d' entrees que 
1 ' instruction courante comporte d'operandes ; 

une — etape — de — depiriement — et — de — veri-f-i-cat±on — que — tes— 

types des entrees au sommet de la pile sont sous-types 

30 des types des operandes de cette instruction ; 
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- une etape de verification de 1' existence d'un espace 
memoire suffisant sur la pile des types pour proceder a 
I'empilement des rfesultats de 1 ' instruction courante ; 

- une etape d' empilement sur la pile des types de donn^es 
attribues a ces r6sultats. 

12. Precede selon la revendication 11, caractferise 
en ce que lorsque 1 ' instruction courante est une 
instruction de lecture d'un registre d'adresse n, le 
processus de verification consiste : 

- a verifier le type de donnee du resultat de cette 
lecture par consultation de 1' entree n du tableau des 
types de registres ; 

- a determiner I'effet de 1 ' instruction courante sur la 
pile des types par depilement des entries de la pile 
correspondant aux operandes de cette instruction 
courante et par empilement du type de donn^es de ce 
rfesultat. 

13. Pr6c§de selon la revendication 11, caracterise 
en ce que lorsque 1 ' instruction courante est une 

20 instruction d'6criture d'un registre d'adresse le 
processus de verification consiste : 

- a determiner I'effet de 1 ' instruction courante sur la 
pile des types et le type t de I'operande ecrit dans ce 
registre d'adresse m ; 

25 - a remplacer l'entr6e de type du tableau des types de 
registres ^ I'adresse m par le type immediatement 
superieur au type pr6cedemment stocke et au type t de 

l-'-opei?^ande— ee-2=HL-t— da-H^^ 

14. Proc§de de transformation d'un code objet d'un 
30 fragment de programme, dans lequel les operandes de chaque 

instruction appartiennent aux types de donnees manipulees 
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par cette instruction, la pile d' execution ne presente pas 
de phenomene de debordement, pour chaque instruction de 
branchement le type des variables de pile au niveau de ce 
branchement est le meme qu'au niveau des cibles de ce 
5 branchement, en un code objet normalise pour ce meme 
fragment de programme, dans lequel les operandes de chaque 
instruction appartiennent aux types de donnees manipul§es 
par cette instruction, la pile d' execution ne presente pas 
de ph§nomene de d§bordement, la pile d' execution est vide 
10 k chaque instruction de branchement et ci chaque 
instruction de cible de branchement, caract§rise en ce que 
ce proced§ consiste, pour 1' ensemble des instructions 
dudit code objet : 

a annoter chaque instruction courante par le type de 
15 donnees de la pile avant et apres 1' execution de cette 

instruction, les donnees d' annotation etant calculees 
au moyen d'une analyse du flot des donnees relatif a 
cette instruction ; 

- a detecter au sein desditg^s in .g;i-rnrt-i nns et de rhaqiiR 

20 instruction courante 1' existence de branchements 

respectivement de cibles de branchements pour lesquels 
ladite pile d' execution n'est pas vide, I'operation de 
detection etant conduite ^ partir des donnees 
d' annotation du type des variables de pile allou§es a 
25 chaque instruction courante, et en presence d'une 

detection d'une pile d'execution non vide, 
a inserer des instructions de transfert des variables 



de pi~]re de part et d' autre de ces branchements 
respectivement de ces cibles de branchements afin de 
30 vider le contenu de la pile d^ execution dans des 

registres temporaires avant ce branchement et de 
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r§tablir la pile d' execution a partir desdits registres 
temporaires apres ce branchement, et a n'inserer aucune 
instruction de transfert sinon, ce qui permet d'obtenir 
un code objet normalise pour ce meme fragment de 
5 programme, dans lequel la pile d' execution est vide a 

chaque instruction de branchement et a chaque 
instruction de cible de branchement, en 1' absence de 
modification de 1' execution dudit fragment de 
programme . ; 

10 15. Proc6d6 de transformation d'un code objet d'un 

fragment de programme, dans lequel les op6randes de chaque 
instructions appartiennent aux types de donn^es manipul§es 
par cette instruction, et un operande de type determine 
ecrit dans un registre par une instruction de ce code 

15 objet est relu depuis ce meme registre par une autre 
instruction de ce code objet avec le meme type de donnee 
determine, en un code objet normalise pour ce m§me 
fragment de programme, dans lequel les op6randes de chaque 
instruction appartiennent aux types de donn^es manipul§es 

TO psr — cette — liisLj-ucliun, — on — s«tti — efe — m&mQ — feype — da — donnpp 

6tant allou§ h un meme registre dans tout ledit code objet 
normalise, caracterise en ce que ce proc6d§ consiste, pour 
1' ensemble des instructions dudit code objet : 

- a annoter chaque instruction courante par le type de 
25 donnee des registres avant et apres 1' execution de 

cette instruction, les donn6es d' annotation 6tant 
calculees au moyen d'une analyse du flot des donnees 
relatif a cette instruction ; 

- h effectuer une reallocation des registres par 
30 detection des registres d'origine employes avec des 

types diff brents, division de ces registres d'origine 
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en registres normalises distinctS/ un registre 
normalise pour chaque type de donnee utilise, et une 
reactualisation des instructions qui manipulent les 
operandes qui font appel auxdits registres normalises. 

16. Procede selon la revendication 14, caracterise 
en ce que I'etape consistant a detecter au sein desdites 
instructions et de chaque instruction courante 1' existence 
de branchements respectivement de cibles de branchement 
pour laquelle la. pile d' execution n' est pas vide consiste, 
suite a la detection de chaque instruction de rang i 
correspondant : 

a associer k chaque instruction de rang i un ensemble 
de nouveaux registres, un nouveau registre etant 
associe ^ chaque variable de pile active au niveau de 
cette instruction ; 

a examiner chaque instruction detectee de rang i et a 
discriminer 1' existence d'une cible de branchement 
respectivement d'un branchement, et dans le cas ou 
1 ' instruction de rang i est une cible de branchement et 
20 que la pile d^ execution au niveau de cette instruction 

n'est pas vide, 

• pour toute instruction precfedente, de rang i-1, 
constitute par un branchement, une lev§e d' exception 
ou un retour de programme, 1 ' instruction detectee de 
25 rang i n^ etant accessible que par un branchement, 

•• a inserer un ensemble d' instructions de chargement 
load a partir de 1' ensemble de nouveaux registres 
anteTTeuremen^t^ 

i, avec redirection de tous les branchements vers 
30 1 ' instruction detectee de rang i vers la premiere 

instruction de chargement load inser6e ; et 
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• pour toute instruction precedente, de rang i-1/ 
continuant en sequence, 1 ' instruction d6tectee de 
rang i etant accessible a la fois par 
l'interm§diaire d'un branchement et de 1 ' instruction 

5 pr^cedente de rang i-1, 

•• a inserer un ensemble d 'instructions de sauvegarde. 
store vers . 1' ensemble de nouveaux registres 
anterieurement a ladite instruction detectee de rang 
i et un enseit±)le d' instructions de chargement load a 

10 partir de cet ensemble de nouveaux registres, avec 

redirection de tous les branchements vers 
1' instruction detectee de rang i vers la premiere 
instruction de chargement load inseree, et, dans le 
cas oh ladite instruction detectee de rang i est un 

15 branchement vers une instruction d6termin6e, 

• pour toute instruction detect§e de rang i constituee 
par un branchement inconditionnel/ 

a inserer anterieurement a 1 ' instruction detectee de 

rang i une plural A tg d' instructi ons de s auvegarde 

20 store , k chaque nouveau registre etant associee une 

instruction de sauvegarde ; et 

• pour toute instruction detectee de rang i constituee 
par un branchement conditionnel et pour un nombre 
m > 0 d*operandes manipul6s par cette instruction de 

25 branchement conditionnel, 

a inserer anterieurement a cette instruction 
detectee de rang i une instruction de permutation, 
swap-x , au sommet de la pile d' execution des m 
operandes de 1 ' instruction detectee de rang i et des 

30 n valeurs suivantes, cette operation de permutation 
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perinettant de ramener au sommet de la pile 
d' execution les n valeurs a sauvegarder dans 
1' ensemble des nouveaux registres, et 
a inserer anterieureitient a 1 ' instruction de rang i 
5 un ensemble d' instructions de sauvegarde store vers 

1' ensemble de nouveaux registres, et 

a inserer posterieurement a 1 ' instruction d6tectee 
de rang i un ensemble d' instructions de chargement 
load a partir de 1^ ensemble des nouveaux registres. 
10 17. Procede selon la revendication 15, caracterise 

en ce que l^etape consistant a effectuer une reallocation 
des registres par detection des registres d'origine 
employes avec des types differents consiste : 

a determiner les interval les de dur^e de vie de chaque 
15 registre ; 

a determiner le type de donnees principal de chaque 
intervalle de dur6e de vie, le type de donnees 
principal d'un intervalle de dur§e de vie j pour un 

reglsLie — r — 6LanL — dSf inl — piST Ta borne superieure aes 

20 types de donnees stockees dans ce registre r par les 

instructions de sauvegarde store appartenant S 
1 * intervalle de dur6e de vie j ; 

a etablir un graphe d' interferences entre les 
intervalles de duree de vie, ce graphe d' interferences 

25 consistant en un graphe non oriente dont chaque sommet 

est constitue par un intervalle de duree de vie et dont 
l es arcs entre deux sommets ji et 32 existent si un 
sommet contient une instruction de sauvegarde adressee 
au registre de 1* autre sommet ou reciproquement ; 

30 - a traduire I'unicite d'un type de donnee alloue a 
chaque registre dans le . graphe d' interferences en 
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ajoutant des arcs entre toute paire de sommets du 
graphe d' interferences tant que deux sommets d'une 
paire de sommets n'ont pas le meme type de donnee 
principal associ6 ; 
- a effectuer une instanciation du graphe 
d' interferences, par attribution a chaque intervalle de 
duree de vie d'un numero de regis tre de telle maniere 
qu'a deux intervalles de vie adjacents dans le graphe 
d' interferences soient attribues des numeros de 
registres differents. 

18. Systeme embarque reprogrammable par 
telechargement de fragments de programmes, comportant au 
mo ins un microprocessetir, une memo ire vive, un module 
d' entrees/sorties, une memoire non volatile reprogrammable 
electriquement et une memoire permanente dans laquelle 
sont implantes un programme principal et une machine 
virtuelle permettant 1' execution du programme principal et 
d'au moins un fragment de programme par 1 ' intermediaire 
dudit microprocesseur, caracterise en ce que ledit systeme 

20 embarque comporte au moins un module de programme de 
gestion et de verification d'un fragment de programme 
telecharg6 suivant le protocole de gestion d'un fragment 
de programme telecharge selon I'une des revendications 1 
ou 2, ledit module de programme de gestion et de 

25 verification etant implante en memoire permanente. 

19. Systeme embarque selon la revendication 18, 
caracterise en ce que celui-ci comporte au moins un module 

de sous-p-rog-iramme de ve-ri-fica-tion d-^un f-ragmenfe de- 
programme telecharge, suivant le processus de verification 
30 selon I'une des revendications 3 a 13. 
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20. Systeme de transformation d'un code objet d'un 
fragment de programme, dans lequel les operandes de chaque 
instruction appartiennent aux types de donnees manipulees 
par cette instruction, la pile d' execution ne pr^sente pas 
de phenom^ne de debordement, pour chaque instruction de 
branchement le type de variables de pile au niveau de ce 
branchement est le meme qu'au niveau des cibles de ce 
branchement et un operande de type determine ecrit dans un 
registre par une instruction de ce code objet est relu 
depuis ce meme registre par une autre instruction de ce 
code objet avec le m§me type de donnee determine, en un 
code objet normalise pour ce meme fragment de programme 
dans lequel les operandes de chaque instruction 
appartiennent aux types de donnees manipulees par cette 
15 instruction, la pile d' execution ne presente pas de 
phenomene de debordement, la pile d' execution est vide a 
chaque instruction de branchement et k chaque instruction 
de cible de branchement, un seul et meme type de donnee 

etant a l lonpt a nn mRme rf=^glstre dans tout ledit code objot 

20 normalise, caracterise en ce que ledit systeme de 
transformation comporte au moins, implante en memoire de 
travail d'un ordinateur de developpement ou d'une station 
de travail, un module de programme de transformation de ce 
code objet en un code objet normalise suivant le precede 
25 selon les revendications 14 et 15, ce qui permet 
d'engendrer un code objet normalise pour ledit fragment de 
programme satisfaisant aux criteres de verification de ce 
fragmen^~de programme telecharge. 
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